[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Macros in Interlisp

Macros in Interlisp are a separate and powerful facility.

There are actually three kinds of macros in Interlisp, as well
as several other facilities which provide features which are
often provided by macros in other Lisp dialects:

Substitution macros (which I assume is what RMS was referring to)
allow one to give a substitution template for a form, e.g.
if BINDVAR's macro is ((VAR VAL . FORMS) ((LAMBDA (VAR) . FORMS) VAL))
then (BINDVAR X Y (FOO)) -> ((LAMBDA (X) (FOO)) Y)

Computed macros correspond to the MacLisp style of macro, where
a variable is bound to the macro body, a form is evaluated, and
the result of the evaluation is used as the macro translation.

While computed macros are more powerful than substitution macros,
the substitution macros have the advantage that they are often
more concice, and have the important property that the result
of macro expansion depends only on the macro instance and the
macro definition.

LAMBDA macros correspond to "inline" definitions, e.g., if the
macro for FOO is (LAMBDA (A B C) (MUMBLE)) then
(FOO X Y Z) expands to ((LAMBDA (A B C) (MUMBLE)) X Y Z).

MACROS are integrated into the system. Macros get expanded during
interpretation (with the macro translation hashed off of the
actual macro body so that while translation only happens once,
the original source is left intact for pretty printing.) If
the user maintains a masterscope database about his functions,
Masterscope will print a warning about which functions need 
recompilation when a macro is changed. [This is conservative
only for substitution and LAMBDA macros, since expansion of
computed macros could depend on arbitrary parts of the compile/runtime

In addition to Macros, Interlisp allows user-defined "CLISP" forms
(e.g., the PUSH, POP, CHANGE etc. expressions were originally done
this way) and extensions to the iterative expressions which allow
user-defined iteration keywords.

Finally, the RECORD package allows declarations of data structure
types which are in actuality macro expansions, via the ACCESSFNS
record type. While this can be thought of as a convenient way
of packaging together a related set of macros, these ACCESSFNS
records are integrated with the record package to provide
for "creation" of new instances, record path tracing, etc.

These facilities have been in place at least since 1978. 

The misconception about macros in Interlisp seems to 
be a common mind-bug. I found references to Interlisp's
lack of macros in Winston&Horn, and also in Charniak, Riesbeck
and McDermott's book. Nonsense.