[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: MASINTER at PARC-MAXC
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Sat ,7 Nov 81 02:17:00 EDT
- Cc: LISP-FORUM at MIT-MC
Date: 5 NOV 1981 2158-PST
From: MASINTER at PARC-MAXC
Macros in Interlisp are a separate and powerful facility...
MACROS are integrated into the system. Macros get expanded during
Date: 6 Nov 1981 14:21 PST
From: Masinter at PARC-MAXC
...The documentation for Interlisp macros is in the chapter on the
compiler. Pages 18.12-13 explains the MACROTRAN facility which
expands macros during interpretation. The documentation is not
particularly clear that macros by default expand once at
interpretation..., but it does say it.
I believe the description of macros and macro expansions should
indeed be moved out of the compiler chapter and into a section on
the interpreter/functions, etc. for the next Interlisp manual
According to the Oct 78 copy of the Interlisp manual, p18.12-13
MACROTRAN is a package that enables the user to run programs
interpretively which contain calls to functions which are only
defined in terms of a compiler macro. MACROTRAN is implemented via
an entry on dwimuserforms (Section 17). [Footnote: and thus will not
work if DWIM is not enabled] When the interpreter encounters a form
car of which is undefined function, macrotran is called. If car of
the form has a MACRO property, the macro is expanded, and the result
of this expansion is evaluted in place of the original form...
Certainly you will be hardpressed to convince me that this is
"integrated" into your system. There is a clear division between the
interpreter and the error signal/correction facility in Maclisp.
Functions, macros, and AUTOLOAD-type things are not errors and are no
business of any DWIM-like facility from my point of view. Coupling it to
something so conceptually unrelated as macros is very poor modularity at
both a conceptual and implementational level. What if someone wanted to
turn off DWIM? Would you argue that he should have to not have macros?
They certainly are a proven tool and I don't think that's a reasonable
penalty to pay. I applaud your idea of moving macros out of the compiler
section but I hope the move will involve something more than just
picking up the text and indexing it elsewhere ...
The change involves a shift in philosophy about what is undefined.
MACROs are certainly defined. 'Tis true they cannot work in all places
functions can, but that's far from undefined. It just means APPLY, and
MAP have a bit of a hard time because there is no full macro form.
The LispM's substs are constrained enough to work like functions though,
and Macsyma's macros don't operate on whole forms so they map and apply.
If macros continue as they are implied to be in current doc as a hack
fix to essentially a bug situation in the interpreter, then I don't know
that I'd agree that you have them at all in your language ... in your
system perhaps, but not in your language. And I think the language is
where it's at. Abstraction is the stuff out of which big programs are
built and needs to be addressed at the heart of the system, not as an