[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Restrictions on what macros may call, to avoid needing to preload file
- To: Common-LISP@SU-AI.ARPA
- Subject: Restrictions on what macros may call, to avoid needing to preload file
- From: Robert Elton Maas <REM@IMSSS.SU.EDU>
- Date: 1985 May 05 17:24:22 PST (=GMT-8hr)
- Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)
- Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
- Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-05 17:26:23 PST (=GMT-8hr)
Today somebody mentionned the problem of having to preload a file of
macros interpreted (in the compiler environment) before being able to
compile that same file, because of the macros needing themselves.
I encountered a more subtle problem which likewise requires preloading
the file of macros. In my case I was being careful not to have a macro
depend on itself, but it did depend on EXPRs in the same file. Loading
the macro interpreted was fine, because first the macro and all needed
EXPRs were loaded, and then any use of the macro occurred, so at that
point everything needed to expand the macro-form was available. But
when compiling, only macros are loaded into the compiler environment,
EXPRs are merely compiled and written to output, not also loaded. Thus
when it came time to compile a function which contained the
macro-form, only the toplevel macro-expander, not the EXPRs called by
the macro-expander, were available. I found I had to pre-load the file
interpreted, then compile it. But then every time a macro was compiled
the second time around the compiler complained about duplicate macro
definitions. (This is with PSL, but the same general problem would
probably happen with any LISP.)
I'm on the verge of rewriting all my macros that have subfunctions to
avoid subfunctions entirely, hacking the same effect by generating
forms that contain sub-macros within them, thus the calling of
sub-expanders happens via the macro mechanism after the toplevel
macro-expander has returned a form to re-expand, rather than from
within the body of the toplevel macro-expander, and the sub-expanders
are all macros instead of EXPRs and thus automatically loaded into the
compiler environment without needing to be pre-loaded interpreted. Is
this change the best approach to avoid compiler hassles, or does CL
provide a way to assure that certain EXPRs will both be compiled to
the output file and loaded into the compiler environment so that one
wouldn't have to do my proposed change?