issue COMPILER-LET-CONFUSION, version 7

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

If you really want to pursue the idea of storing COMPILER-LET bindings
in the environment, perhaps we should try to revive another idea that
was suggested by Pitman some time ago in this connection:

> Suppose that instead of referencing the value as a special, you had 
> an operator COMPILER-SYMBOL-VALUE to get its value. [That could be a 
> function, macro, or special form.] I wouldn't have a problem calling
> a function to get this data because I still get to use the same basic
> `shape' of code. Also, uses of COMPILER-LET are rare enough that a
> bit of extra syntax is not overwhelming.
> 
>  (DEFMACRO mac (...) 
>    ... (COMPILER-SYMBOL-VALUE name) ...)
> 
>  (new-COMPILER-LET ((name val))
>    ...)
> 
> I don't know how other supporters of COMPILER-LET would feel about this.
> It looks ok to me, though.
> 
> I can't think of any implementations in which this would be prohibitively
> expensive to implement.

COMPILER-SYMBOL-VALUE would also have to take an optional environment
argument, of course.

As I've pointed out before, it's possible to implement something like
this already by using SYMBOL-MACROLET as a primitive, provided that
you're willing to do without SETF'ing the "variables".  Kent has
complained that he doesn't like the idea of having the symbol macros
shadow the normal (lexical or special) bindings of the variable that
would be visible at runtime, though.  (Personally, I believe anybody
who uses the same variables in a COMPILER-LET that are also used at
runtime in the same lexical scope is asking for trouble anyway.)

If the shadowing problem could be sorted out, I wouldn't object to
seeing this firmed up into a real proposal to redefine COMPILER-LET to
work this way.  You'd also have to add a keyword argument to
AUGMENT-ENVIRONMENT, and something so you can tell whether a variable
has a COMPILER-LET "binding" or not.

-Sandra
-------