[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential issue: MACRO-SPECIAL-FORMS
- To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Thu, 23 Feb 89 16:00:17 MST
- Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
- In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Thu, 23 Feb 89 22:00:42 GMT
I've been burned by this problem more than once myself. A few
additional observations:
I just recently ran into a problem with Lucid Lisp expanding things
like DEFUN into something that included (FUNCTION (NAMED-LAMBDA ...)).
In other words, it's a valid Common Lisp special form but not valid
Common Lisp syntax for that form. Perhaps a better restriction than
"macros must not expand into implementation-dependent special forms"
would be "macros must expand into code which has Common Lisp syntax".
Once I ran into a problem in VaxLisp where one of the multiple value
macros was treated as a special form by the compiler. It
macroexpanded into some really terrible code and I was getting a
noticible performance hit by having my codewalker just blindly
expanding it. Even though the macro definition was semantically
correct, I ended up adding a whole bunch of macros to the list of
things my codewalker treated as "special forms". I suspect that other
implementations do similar things -- I know my A-Lisp compiler also
treated some of the multiple value macros specially as well.
It ought to be OK for things that are documented as special forms to be
implemented as macros that expand into other implementation-dependent
special forms, since code analyzers are expected to have special
knowledge about them instead of using the macro expansion.
-Sandra
-------