[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 29 01:11:18 1993 
Subject:Re: Not a bug but a feature? 
From:Aaron Sloman 
Volume-ID:930629.03 

pop@dcs.glasgow.ac.uk (Robin Popplestone) writes:

> Organization: Computing Sci, Glasgow Univ, Scotland
> Date: Mon, 28 Jun 1993 13:30:43 GMT
>
> Helen McCall writes in <C96CwG.9s7@cs.bham.ac.uk>:
>
> > I  have  recently  worked  right  through  all  my  POP-11  code   and
> > modularised it in POP-11 sections. When I came to run it  yesterday, I
> > found that well tried and tested code no longer functioned!
>
> > I have found the problem, and need an answer urgently.
>
> > I have used the matcher arrow  '-->' frequently, eg for assigning  the
> > bounds of arrays to limiting arguments in for-loops.

You can now do things like

    explode(boundslist(array)) -> (xlo, xhi, ylo, yhi);

which is more efficient and works with sections and lvars.

[robin]
> As has been explained, this is NOT a bug in the implementation of POP-11. It
> is however a bug in the language design. Some aspects of POP-11 represent
> features of the language that make simple things easy but are inimical to good
> software engineering, and the matcher is one.

There are not so simple things that the matcher makes easy. E.g.
suppose you have a list of lists, and you want to find whether one
of the lists contains occurrences of "tom" and "dick" and if so
you want to make a list of all the intervening items.

vars list_of_lists =
    [ [ 1 2 3 tom]
      [dick 4 5 6]
      [7 tom 8 9 10 11 12]
      [13 14 tom 15 16 17 18 19 dick 20 21]
      [ tom 22 23]];

define list_between(start, fin, list) -> result;

    lvars list, start, fin;
    vars result;

    unless list matches [ == [ == ^start ??result ^fin == ] == ] then
        false -> result
    endunless;

enddefine;

list_between("tom", "dick", list_of_lists)=>
** [15 16 17 18 19]

Doing that without the matcher would require several nested loops
or recursive calls, and would be hard for most people to get right
first time. Programming with patterns aids readability,
maintainability and speed of development. The main benefit comes
from the availability of "segment" pattern elements (not provided
in standard Prolog, for example, except when the segment is the tail
of a list).

You can get all the above in Pop-11 with lexical variables or
section variables using LIB FMATCHES, as someone pointed out.

Also with the ordinary matcher you can use sections if you take care
to use not ordinary words for you your pattern variables but
word-identifiers, which are guaranteed to access values appropriate
to the section at compile time. See REF * SECTIONS

    word_identifier(WORD, SECT, CONTEXT) -> WORD_ID         [procedure]
        This procedure enables sectioned  identifiers to be  represented
        by unique word records.
        ....

Unfortunately special syntax is needed to get word identifiers
into lists. Perhaps this will be available for the next
version of Poplog Pop-11

> The real issue is the treatment of free variables. The variables occurring in
> a pattern are in effect free - it is only by accident that they are bound
> as required in most uses of the matcher.

That's because the standard matcher uses "valof" applied to the
words in the pattern list.

In LIB FMATCHES the list contains identifiers not words. It would be
possible to use word_identifiers with the standard matcher, though
new post V14.2 syntax is needed to make this work easily. (Not even
then perhaps.)

> The habit of using the matcher as a general purpose variable binding mechanism
> is a bad one,

I agree, except where the matcher is doing more than simplifying
assignments.

> ..inculcated by texts not intended for the consumption by serious
> computer scientists. There are circumstances where it provides a solution more
> succinct than any other available in the language, and in these circumstances
> one might regard it as good practice to use it.

Usually fmatches is safer. (It also, thanks to Jonathan Cunningham),
deals with some special cases the ordinary matcher can't handle, at
the cost of slightly reduced efficiency, because they need
backtracking, e.g. here's a little constraint satisfaction problem,
for which matches fails to find the solution, and which fmatches
solves:

    [[1 2][2 1]] matches [[??x ??y][??y ??x]], x, y=>
    ** <false> [] [1 2]

    uses fmatches
    [[1 2][2 1]] fmatches [[??x ??y][??y ??x]], x, y=>
    ** <true> [1] [2]

The Alphapop matcher, which Jonathan implemented, gets this right
(but can't handle section variables).
Aaron
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281