[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue EVAL-WHEN-NON-TOP-LEVEL, v2
- To: cl-compiler@SAIL.STANFORD.EDU
- Subject: Issue EVAL-WHEN-NON-TOP-LEVEL, v2
- From: Kim A. Barrett <IIM@ECLA.USC.EDU>
- Date: Sat 31 Dec 88 19:42:42-PST
- Cc: iim@ECLA.USC.EDU
> Date: Wed, 21 Dec 88 20:21:57 PST
> From: Jon L White <firstname.lastname@example.org>
> Subject: issue EVAL-WHEN-NON-TOP-LEVEL, version 2
> Since we are tending towards flushing COMPILER-LET, then I favor restricting
> the COMPILE situation to "toplevel" forms.
I'm not sure what the proposed flushing of COMPILER-LET has to do with this.
And what do you mean by "restricting" the COMPILE situation to top-level forms?
You can't say that the COMPILE situation is flat-out illegal except at
top-level if you want both DEFINING-FORMS-NON-TOP-LEVEL and the discussion of
using (EVAL-WHEN (COMPILE) ...) to perform the compile-time magic of defining
macros, as described in COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.
I agree wholeheartedly that we need to tighten up the definition of
"top-level". I have a strawman proposal roughed out mentally, but haven't had
time to actually write it down. Maybe this weekend, since I seem to be in
> "When an EVAL-WHEN form is processed by the compiler:"
> lists two alternatives in a way that might imply they are mutually
> (1) If the situation COMPILE is specified:
> (2) If the situation LOAD is specified, ...
> One needs to cover the case when both COMPILE and LOAD are specified.
That's supposed to be a two step process. First the compiler does the stuff in
(1). Then it does the stuff in (2). The supplied macro definition for
eval-when makes this clear, but is placed far away.
> In addition, does the compiler act differently on situation (EVAL) than it
> does on situation (LOAD)? How about (EVAL LOAD)?
The compiler completely ignores the EVAL situation. It is only interested in
whether the COMPILE situation is present (if at top-level), and if the LOAD
situation is present (always). I seem to remember that Spice Lisp had the
compiler processing non-top-level EVAL situations in the way the proposal says
to handle LOAD, so Lucid may have inherited this (assuming I'm correctly
informed about the ancestry of some of Lucid's work). Early on we decided to
change away from Spice to our current interpretation (which is essentially what
the proposal consists of).