[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue COMPILER-LET-CONFUSION, version 1
- To: David N Gray <Gray@dsg.csc.ti.com>
- Subject: Re: Issue COMPILER-LET-CONFUSION, version 1
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Wed, 5 Oct 88 16:02:10 MDT
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: David N Gray <Gray@DSG.csc.ti.com>, Wed, 5 Oct 88 14:07:38 CDT
> Date: Wed, 5 Oct 88 14:07:38 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> > Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:
>
> This alternative might appear more attractive if it were clarified that
> the "compatibility problems" only apply to macros used within function
> definitions contained in the body since they are not executed during
> execution of the COMPILER-LET.
No, there are other cases as well. Consider this one:
(eval-when (eval compile load)
(defvar *silly* nil)
(defmacro silly-macro () `(quote ,*silly*)))
(let ((*silly* (cons 'let *silly)))
(compiler-let ((*silly* (cons 'compiler-let *silly*)))
(silly-macro)))
If the interpreter performs evaluation in parallel with macro expansion,
then SILLY-MACRO will see the value of *SILLY* as (COMPILER-LET LET),
but in the compiler (or a preprocessing interpreter) it will only see it
as (COMPILER-LET). Of course, similar problems can occur when macros
rely the values of special variables, even when COMPILER-LET is not
involved.
You're right, though -- the writeup should go into more detail on this.
> > Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:
>
> I'm leaning in favor of a variation of this approach that would say that
> if an implementation does not normally do a preprocessing code walk, then
> the evaluator's implementation of COMPILER-LET needs to do a macro
> expansion code walk on its body forms before evaluating them. We
> currently do macro expansion as needed during evaluation, yet it would be
> a trivial change to have COMPILER-LET invoke MACROEXPAND-ALL on its body.
> This should only be a hardship for any implementation that doesn't do a
> pre-pass and doesn't already have a MACROEXPAND-ALL.
I suspect that most implementations that don't do a code-walking prepass
in the interpreter don't have anything like MACROEXPAND-ALL, either, so
this may not really buy anything. I suppose this could be presented as
yet another alternative in the next iteration of the writeup on this
issue. Does anybody else like this idea?
-Sandra
-------