Pop-11 Pattern variables: the ANSWER?? 
Author Message
 Pop-11 Pattern variables: the ANSWER??

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



Fri, 15 May 1998 03:00:00 GMT  
 Pop-11 Pattern variables: the ANSWER??

Steve,

Thanks for the comment.

Quote:
> > 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.

> Sadly, lib fmatches is not made redundant.  Firstly, fmatches does not
> suffer from the multiple segment matching defect of matches and that
> alone makes it indispensible.

I've reimplemented that in the new cleaner operator doesmatch, available
in
        ftp://ftp.cs.bham.ac.uk/pub/ dist/poplog/auto/doesmatch.p

which also works with ordinary pattern variables. (I can email it if
anyone has trouble getting it via ftp. )

However, like fmatches it will generate unnecessary garbage if you do
not need a solution to the multiple segment matching problem because all
your patterns have a simple enough structure for the old matcher to
cope.

Actually all three matchers generate garbage because of the temporary
creation and release of lists of variables that have been bound
(popmatchvars). I should have a go at restoring these to the free list,
or perhaps replacing popmatchvars with a long re-usable vector?

Quote:
> ...More importantly, fmatches does not
> suffer from the data/pattern confusion of matches which makes matches
> inherently dangerous.

I don't understand this. Can you elaborate?

A very serious problem with fmatches is that all patterns have to be
inline. I.e. you cannot pass a pattern as an argument to fmatches and
therefore it is useless for defining procedures which e.g. take lists of
patterns as arguments and iterate over them, or which take a pattern and
a database, etc.

Could it be that this flaw is what you regard as a benefit, i.e. you
think patterns should be regarded as code not as data?? That's a
distinction I prefer to abolish!

Aaron



Fri, 15 May 1998 03:00:00 GMT  
 Pop-11 Pattern variables: the ANSWER??

Quote:
Aaron writes:
> 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.

Sadly, lib fmatches is not made redundant.  Firstly, fmatches does not
suffer from the multiple segment matching defect of matches and that
alone makes it indispensible.  More importantly, fmatches does not
suffer from the data/pattern confusion of matches which makes matches
inherently dangerous.

Steve



Fri, 15 May 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Pop-11 Pattern variables: the ANSWER??

2. Regular expression string pattern matching: Embedding pop-11 procedures, and more

3. Pop-11 Eliza answers 1000 questions

4. A POP-11 Book Available via FTP

5. calling prolog from pop-11

6. Pop-11 Procedures for encoding and decoding BASE64 files (mimencode)

7. Development of Pop-11 for Windows

8. GSL interface: another Pop-11 development task?

9. vectors in pop-11

10. Running Pop-11

11. forwarding message from Steve Leach re Running Pop-11

12. Pop-11 XML tools by Steve Leach

 

 
Powered by phpBB® Forum Software