Re: issue COMPILER-LET-CONFUSION, version 7

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Tue, 14 Mar 89 12:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> What is the interaction between proposals COMPILER-LET-CONFUSION
> and DEFINE-OPTIMIZER?  Neither proposal says anything about that
> as far as I can see.  I believe the body of a optimizer must be
> executed in the same dynamic environment as the body of a macro.

I think you're right about this.

> A possible implementation technique for such
> interpreters, in fact the one I would use, is to save the COMPILER-LET
> bindings in a slot in the interpreter's lexical environment in the form
> of an alist, and to make the MACROEXPAND-1 function bind those bindings
> with PROGV around its call to the macroexpander.  Using this technique
> instead of fully macroexpanding the body deals with some of the
> objections to the REPAIR proposal, I believe.  Also promoting this
> technique in the proposal would remove the need for the discussion
> section to address the side-issue of whether code analyzing programs can
> or cannot be written portably (an important issue in its own right, but
> not part this one).

An earlier version of this issue actually contained a proposal
REDEFINE that suggested doing this very thing.  However, it didn't
seem like it had much support, and it had the problem that it could be
subverted by programs that call the MACRO-FUNCTION directly. 

Kent mentioned a similar implementation technique in his first
iteration on proposal REPAIR (in which it was the responsibility of
the compiler or interpreter to bind the variables before calling
MACROEXPAND-1).  I removed it partly because it would be even easier
to subvert than the earlier REDEFINE proposal, and partly because it
looked like we were going to get bogged down in a discussion of
side-effecting the variables.

>     Current Practice:
>   
>      Some implementations (the ones from which COMPILER-LET originally came)
>      continue to use their pre-CLtL semantics. These semantics are useful, though
>      incompatible with CLtL (which they largely consider to simply be in error).
> 
> Could you be more explicit about this?

Kent, since this is your language, can you do something about this?  This
is the second complaint we've gotten about this particular statement.
I must admit that I am also not sure how the pre-CLtL semantics differ
 from the CLtL semantics.

-Sandra
-------