Re: issue COMPILER-LET-CONFUSION, version 7

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 14 Mar 89 11:05:22 MST
    From: 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>

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

I wouldn't take that problem too seriously, for two reasons.  First,
the CLtL writeup on MACRO-FUNCTION says you should call MACROEXPAND
rather than calling the function directly.  Second, if you think about
where the second argument to the function comes from, it's unlikely
that (funcall (macro-function ...) ...) could be used anywhere but
inside a macro expander, where the special variables are bound,
especially if MACRO-ENVIRONMENT-EXTENT:DYNAMIC passes, except when
the environment is explicitly null, in which case there cannot be
any COMPILER-LET anyway.

    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.

I hadn't thought of side-effecting the variables.  It's important for
the language specification to say something about that.  I can't justify
forbidding it (the only reason for forbidding it I can think of is
efficiency, and that's minor here), so I think it should be explicitly
allowed.  This means that places that PROGV will have to copy the values
back.  Alternatively it could be explicitly forbidden; I'd rather see
that than see nothing.  I believe I have seen some programs that used
COMPILER-LET to bind a variable in which subsidiary macros collected
information, so side-effects are used, however those programs may have
been unportable anyway.

Note that this issue of side-effecting the variables is completely
orthogonal to everything else.  It's not tied up with this question
of implementation technique.