Not a bug but a feature? 
Author Message
 Not a bug but a feature?


Quote:
> 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.
> Unfortunately this  language  feature  does not  operate  from  within
> sections.

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.

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.

Faced with the fact in the '60's few compiled languages handled free variables
completely correctly (CPL would have to be the obvious exception) we opted for
dynamic locals as the only kind of local variables in POP-2. Partial
application together with manual lambda lifting provided the way of handling
free variable problems. However this approach left itself wide open to various
kinds of hackery, particularly with respect to matching. This is good for
rapid prototyping, bad for engineering standards.

With the introduction of lexical variables in POP-11, much of the convenience
of pattern matching can be had quite cleanly by constructs like:

lvars (H,T) = dest(L);

This meshes nicely with abstraction mechanisms, since if you regard an
abstract data-type as being:

  constructor+destructor+ whatever selectors you need

then you have a perfectly good, pattern matching interface to the abstract
datatype. This is better than ML, where pattern matching can only be used
for concrete datatypes.

The habit of using the matcher as a general purpose variable binding mechanism
is a bad one, 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.

Robin.

***
very few even of today's computer languages handle free variable correctly. C
doesnt even try, and the "solutions" promulgated for the likes of Pascal
prevent functions being first class citizens. ***



Fri, 15 Dec 1995 21:30:43 GMT  
 Not a bug but a feature?

Quote:

> Organization: Computing Sci, Glasgow Univ, Scotland
> Date: Mon, 28 Jun 1993 13:30:43 GMT


> > 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]

Quote:
> 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{*filter*} 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

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

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

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

Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281



Sat, 16 Dec 1995 09:11:18 GMT  
 Not a bug but a feature?

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

The way to make the matcher intoa really useful tool would be to make
it a first class part of the language. "matches" and ---> would need
to be known to the compiler and a pattern would be a special kind of
thing rather than just a list which is interpreted at run time.

      ^_^
     (O O)

      \\~~/
        ~~
                - RJC



Sun, 17 Dec 1995 23:21:28 GMT  
 Not a bug but a feature?

Quote:
>The way to make the matcher intoa really useful tool would be to make
>it a first class part of the language. "matches" and ---> would need
>to be known to the compiler and a pattern would be a special kind of
>thing rather than just a list which is interpreted at run time.

Thats effectively what fmatches does.

An idea that has bounded around for a while is to introduce a special kind of
ref to the system which can have an 'unassigned' contents, and which is
treated specially by `=', i.e. if its contents are unassigned then `=' returns
true and as a side effect sets the contents to the item that it is equal to.
If it has an assigned contents then `=' returns true only if the contents
are = to the item.

Call this special unifying ref a 'uniref', whose field is called 'unicont'.
We could do:

   lvars funny = newuniref();

   [1 2 3] = [1 2 ^funny] =>
   ** true

   funny.unicont =>
   ** 3

;;; note that:
   funny = 3 =>
   ** true

;;; and:
   funny = 4 =>
   ** false

With some simple syntax a mechanism like this would be far more useful
to me than the matcher is.

e.g. a macro called -uniref- which declares an lvars, initialises it to an
unassigned uniref, and returns the uniref. This allows you to simplify the
above statement to:

   [1 2 ^uniref funny] = [1 2 3] =>
   ** true

   funny.unicont =>
   ** 3

Comments?

Jon.



Mon, 18 Dec 1995 02:32:27 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Not a bug but a feature?

2. uinref (was Re: Not a bug but a feature?)

3. Why is this a feature, not a bug?

4. possible a bug (not a feature)

5. Bug #1464 in bug database is *not* fixed in Tcl/Tk 8.3.2

6. expr bug report not a bug

7. Why are some windows feature not included?

8. Why not undefine deferred features ?

9. Why con constant features not be redefined?

10. Error : Unsupported feature error: non-locally-static attribute names are not

11. ALTERA MAXPLUSII VHDL featured not supported!

12. f77 "features" NOT in g77

 

 
Powered by phpBB® Forum Software