pop@lastresort.cs.umass.edu (02/13/91)
Having read a lot of recent correspondence on comp.lang.news, it seems to me that the LISP world is stuck in a groove from which it could advantageously be lifted by a little abstraction. The LISPer's view seems to be that of a 2-layered approach, namely there is the virtual machine provided by the operating system (OSVM for short) upon which is built a version of LISP. This OSVM is close to the real machine - the only modification made by the operating system is that of address mapping and the provision of system calls in place of real I/O. There is a 3-layered approach, developed by Aaron Sloman, John Gibson and Steve Hardy, and embodied in the POPLOG system. This provides: (a) The OSVM (b) An intermediate virtual machine (IVM). (c) The user languages (Common LISP, ML, POP-11, Prolog) This has the virtue that the semantic capabilities necessary for symbolic processing are (fairly) compactly represented in the IVM and can be presented to the user in the style of the language of his choice. In effect, it goes a considerable way towards making semantics orthogonal to syntax. Storage administration, environmental support and the arithmetic capabilities required for computational algebra constitute a considerable superstructure to be built upon the OSVM, which means that using the IVM. gives a language implementor a flying start, without burdening him with the linguistic baggage of Common Lisp, not to mention its store-hungriness (a minimal POPLOG image can be below a megabyte). Given my own beliefs that languages should evolve towards a tight succinct formalism involving mathematical typography presented via (e.g.) Pantechnicon, with a commentary in real english rather than pseudo-english, I am strongly in favo(u)r of the IVM approach. The con- side of this arrangement is that such an IVM is liable to build in a bias. The Poplog VM has a bias towards Common Lisp, POP-11 and ML, and away from Scheme and Prolog in that it stacks Procedure Activation Records. Thus continuations have to be implemented either using the [1972] POP-2 technique of parcelling up the stack in a "frozen state" on the heap, or by Chris Mellish's ingenious technique [c.1983] (which works OK for Prolog), of creating a continuation to be passed into a procedure/function/predicate (they are all the same data-type in POPLOG). Another bias, derived from POP-11 is the provision of the "updater slot" in procedures. In POP-11 (following POP-2, and related to the "left hand value" idea of CPL and C) the statement: x -> f(y) is treated as updater(f)(x,y) [c.f. the T use of "setter"] However these biases could itself be removed by a more abstract view of the IVM, allowing the provision of an agreed functionality optimised according to user need. E.g. the activation of a procedure could be implemented either by allocation off the stack (in which case creating a continuation needs to be a `parcelling up' operation) or by allocation off the heap. Likewise the updater could be implemented as a property-function rather than as a data-structure slot. I must admit to finding the leaner-meaner Scheme philosophy attractive when it comes to thinking what should go into an IVM., but it is necessary to be able to get it to generate reasonably efficient code. That is, there need to be ways of generating fix-add instructions, indexed accesses to data-blocks etc.. These are achieved as a result of the declarations of Common Lisp, and (somewhat inelegantly) by the fi_... and fast_... procedures of POP-11. And one really needs to ensure that floating point is not an albatross hung about the neck...