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