[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 27 03:46:57 1995 
Subject:Pop-11 Pattern variables: the ANSWER?? 
From:A . Sloman 
Volume-ID:951128.01 

Having complained about the Draconian decisions recently taken regarding
the use of "vars" in procedure definitions, I have now found that Poplog
version 15 has introduced a new feature which perhaps nearly compensates
for that.

It's something I requested some time ago, but I did not know it had been
done, namely allowing valof and its updater to work on identifiers as
well as on words.

This is profoundly important because the Pop-11 pattern matcher uses
valof. The generalisation of valof means that in order to allow the
matcher to work with lvars and section variables, all we need to do is
make sure that patterns contain idents (identifier records) rather than
words, after "?" and "??". (See REF IDENT)

To facilitate this I have installed a new library at Birmingham which
is accessible by ftp at the addresses below.

LIB READPATTERN makes available a procedure readpattern in terms of
which a new syntax operator is defined, namely "!". This can precede a
list expression, in which case the list is transformed to contain
identifier records replacing pattern variables, e.g.

	vars pp, qq; ![?pp ison ?qq] =>

    ** [? <ident <undef pp>> ison ? <ident <undef qq>>]

Such expressions can then be used as patterns accessing lvars. This and
other new facilities are described in my new HELP * DOESMATCH, also
available by ftp.

It also describes two additional libraries, LIB DOESMATCH and LIB
WHILE_MATCHING. Between them the three libraries generalise and replace
the old LIB FMATCHES.

Here's an example of the new syntax:

uses readpattern;

define list_between(item1, item2, list) -> found;
    ;;; Here found is automatically declared as lvars, as are the
	;;; input variables in Poplog version 15. but just to make the point
	;;; we declare it lexical

    lvars found;

    unless list matches ![== ^item1 ??found  ^item2 ==] then
        false -> found;
    endunless;

enddefine;

;;; Now test the procedure

vars words = [a b c d e f g];

list_between("a", "g", words) =>
** [b c d e f]

list_between("c", "g", words) =>
** [d e f]

list_between("g", "e", words) =>
** <false>

The generalisation of "valof" makes a huge difference to what you can do
with the Pop-11 pattern matcher, and makes LIB FMATCHES redundant, at
last.

Moreover, the use of "!" with patterns means that the existing Pop-11
database facilities can be used with lvars and section variables, e.g.
present, lookup, foreach, remove, flush, allpresent. There are a few
exceptions, e.g. which need to be generalised.


There were two further ways in which fmatches extended matches apart
from the use of lvars and section variables.

(a) it handled a wider class of matches involving segment variables.
(b) it allowed a "where" condition, or an extra procedure to check the
    satisfactoriness of a match.

Both (a) and (b) are handled by my new library LIB DOESMATCH, and extra
looping syntax is provided by LIB WHILE_MATCHING

It is possible to use doesmatch as a new value of the identifier
matches, in which case other Pop11 procedures inherit the extra
flexibility (and also the extra run time cost in memory management).

Here are addresses of the files.
	ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/help/doesmatch
	ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/lib/readpattern.p
	ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/auto/doesmatch.p
	ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/auto/while_matching.p

Comments welcome, especially regarding the choice of "!" to transform
patterns. Is that widely used for other purposes?

We also need something to transform a list of words to a list of
identifier records. I thought of using !![ ....] for that. This is
needed for things like the procedure which.

I guess we have all been waiting for a new improved version of the
matcher. No doubt something more general and flexible could be designed,
but
	(a) it will probably be a long time a-coming
	(b) it would need massive amounts of new documentation.

I am therefore happy to settle for the present matcher (and doesmatch)
enhanced with the use of ![ ..... ] for patterns, to make the variables
lexically scoped.

I'll have a look at the possibility of generalising poprulebase to take
account of this.
Aaron