ALBERGA@IBM.COM (Cyril Alberga) (05/31/88)
No, that is not the only way macros work in lexically scoped lisps. In LISP/VM
they work pretty much as you would expect, execpt sometimes.
Quick aside: LISP/VM uses a single value cell, a la SCHEME. It support
dynamic (FLUID) bindings, in the same binding contour as lexical bindings.
It has an operator, STATE, which can be used to duplicate CALL/CC. Macros
are first-class objects, written as (MLAMBDA ...). The scope rules for
macros are identical to those of functions.
The trouble is, this makes compilation hard. LISP/VM cheats. The compiler
is presented with two environments. One is used to resolve operators, the
other to apply macros. The first allows the compiler to receive macro
definitions which differ from the run-time definitions. For example, compiled
calls to functions with fixed numbers of arguments is faster than calls with
indefinite trailing arguments. On the other hand, macros may not be applied
(unlike FRANZ-LISP). Thus the run-time environment has a function, PLUS, which
takes indefinite numbers of arguments, while the compiler has a macro, PLUS,
which expands to nested calls to internal-PLUS, a two argument function.
The conceit is that compiler/interpreter equivalence only holds AFTER the
macro expansion phase of the compilation process. It turns out that in
most cases this causes not trouble. Since there are both EVAL and APPLY
operators, and since they accept environments, all lexical variables are
accessible to mixed compiled and interpreted code. (I know this is a
violation of lexicality, but it seemed like the lesser of many evils.)
I should comment that in LISP/VM thinks are a bit more complex. This is
because no operator is examined before evaluation. Thus a function is
not a list with first element LAMBDA, but a list whose first element
evaluates to LAMBDA. The problems arise when an operator evaluates
to (FOO ...), and then FOO evaluates to MLAMBDA. The currently defined
semantics in LISP/VM seem to cause minimal astonishment, but they are
still a bit too baroque for my taste. Trouble is, no-one has suggested better.
Yours,
Cyril N. Alberga