The open stack is not such an offence against theory as many would have
us believe - it is certainly possible to write a lambda-abstraction that
does not reduce to an abstraction-free form after a fixed number of
applications. The theoretical problem is the weakness of type-theories,
which cannot assign a type to such a beast. I have looked at the
possiblity of a grammatical approach to type (a function parses the stack
for its inputs...). The problems of grammar which arise are
theoretically soluble, but at a some expense. Also quite a lot of POP
constructs (e.g. putting the number of arguments on the stack, rather
than a stack-marker) are not treatable grammatically.
POP, which may be thought of as being built upon a modified lambda-calculus
machine, can be criticised for obscuring the non-associative nature of
function application, and therefore requiring a separate concept of partial
application. We did put some thought into whether or not to carry the open
stack from POP-1 (which was more or less an assembler for a stack machine -
a point of view subsequently adopted by Forth and PostScript). To me the
compelling argument was not the [%.....%] way of making lists (invented
by Rod Burstall, who might wish to live it down) but the need to implement
arrays as "memoised" functions (the term "memoised" was invented by Donald
Michie, who proposed the most general form of the concept). An array had to
be a closure of a variadic function, which was most easily supported by
leaving the stack open.
One final virtue of the open stack is that it provides for the associative
combination of the results of procedures. This is something that is often
desirable, where for example some kind of translator wants to produce a
linear sequence as its output.
Robin.
|