As one of the chief miscreants responsible for the syntax, I could say
"Look mister, 'e dun it too". List syntax in POP was originally borrowed
from LISP, without the excuse that it was program syntax anyway, and
without a quote in sight. Not to mention "X = Y+3." which must have led
many a Prolog neophyte astray.
So [the fat cat] was the original form. Then Rod Burstall came up with
the neat hack of marking the stack, and making a list of anything
subsequently stacked, for which the original syntax was
<< stack(your,args) >>.
This was "rationalised" to [% stack(your,args) %]. Probably if we had
had a supply of curlies in the early days we would have used {this is a
list} as being somehow suitable for lists as set-like things (and perhaps
we would have been wrong - certainly it is no help to think of an
application as a set!, and certainly we tended to use [+ x y] to have its
LISP meaning for algebraic simplifiers and the like.)
But I think that a rationalisation is definitely called for. There are
just too many confusing ways of expressing a list which have accreted.
My pet HATE is having to declare my lexicals as lvars. I have from time to
time tried to do little hacks to avoid this, but have not got a stable one.
Also, while we are at it, the control variable of a for loop should be
automatically local to the loop. All these things are being incorporated in
Pepper.
Another thing I would like is a neat, concise syntax for anonymous
functions. The old LAMBDA .......END construct was painful enough, without
being replaced by procedure.....endprocedure. ML's fn <patt> => <body> is
neat.
On a more radical note, I have been doing some C programming recently. Now
as far as the semantics of C go, it feels rather like wiring one's house
with bare copper. But one has to admit that the syntax has a certain
concise elegance. Try out a CPOP (Popsie is already spoken for)
maplist(x,f) { x=[]?[]:f(x)::maplist(tl(x),f)}
POP semantics could be preserved if one made the equation
A[x] = A(x) = x.A
An interesting point is whether there is any way of getting rid of the
distinction between application and partial application, which is not a
fundamental distinction of the lambda calculus, but is only (there) an
implementation issue. A related problem is that partial application
in POP-11 "works backwards", as compared with the lambda calculus (and
therefore ML and Haskell). This is a real problem in mixed language
working, because there are actually some arguments that are more usefully
partially applied than others. E.g. we (Burstall and I) chose the order of
arguments in maplist so that the function argument could be bound by
partial application. The order is OPPOSITE in ML.
One reason for this is that I at least was strongly influenced by the
practice of algebraists, who tend to write operators postfix. Hence we
allowed x.hd as a synonym for hd(x), and defined function product with the
algebraic convention. If one is homming a little hom to oneself in a
category this all makes sense - one is simply following the arrows. There
is a related problem with matrices - do you write them operating postfix on
row vectors (the convention in graphics) or prefix on column vectors
(as do most engineers and physicists).
However the lambda calculus lambda v1...vn.E is really shorthand for
lambda v1 lambda v2....E,
so that the v1 is the first variable to be bound in a beta-reduction, and
hence should be taken off the top of the stack. POP does it the other way.
Robin.
|