[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
-------