[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 28 13:30:43 1993 
Subject:Not a bug but a feature? 
From:Robin Popplestone 
Volume-ID:930628.01 

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.

> 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. ***