Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)

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

    Date: Wed, 15 Mar 89 11:40:35 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Wed, 15 Mar 89 12:10 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > Not if you have DESTRUCTURING-BIND.  But I guess that hasn't been
    > accepted into the language yet.

    Is there a cleanup proposal afoot to add this?  I don't remember seeing
    this on the list Larry distributed at the last meeting.  

It's a new issue:

!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote

==================================================

    >   PARSE-MACRO name lambda-list body &optional env		[Function]
    > 
    >   Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
    >   Returns a lambda-expression that accepts two arguments (form and env)
    >   and returns the macro expansion.

    If this function doesn't actually do any evaluation to construct a
    real function, is it really necessary to have it accept an environment
    argument?

It used to need it in case it had to expand macros in the body to see if
they were declarations, but we got rid of that feature.  I think it
might need it in some implementations to expand macros in order to do
code analysis on initialization forms for optional/keyword/auxiliary
variables in the lambda-list.  I think it's always better to give an
environment argument to functions like this; in principle a form has no
meaning except in the context of an environment, and any function that
takes a form, or something containing forms, as an argument should take
an environment as an argument also.  This would be more obvious if the
null lexical environment contained nothing, rather than containing the
bulk of the language.

==================================================

    Also, a long time ago we passed a cleanup issue saying that the body
    of a macro definition established with MACROLET or DEFMACRO has an
    implicit BLOCK around it.  Unless you want the "body" argument to
    already include the BLOCK, you need the "name" argument for this
    purpose.  Let's be explicit about it, one way or the other.

You're right, I forgot this.  PARSE-MACRO should definitely put in
the BLOCK.

==================================================

I didn't see any mail follow-up on this idea:

  Symbolics Genera includes an undocumented internal macro, used
  quite a bit in the implementation of the interpreter and code
  analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
  taking keywords like AUGMENT-ENVIRONMENT and also body forms,
  and producing an environment with dynamic extent bound to a
  variable within the body forms.  Would it be useful to have this
  too, or instead of AUGMENT-ENVIRONMENT?  I'm unsure.

I wasn't able to think of any applications for AUGMENT-ENVIRONMENT
that would not be happy using WITH-AUGMENTED-ENVIRONMENT instead.
That certainly does not prove that there aren't any.

==================================================

    > The possible interpreter implementation of COMPILER-LET I mentioned
    > in another message earlier today would seem to require another
    > keyword argument to AUGMENT-ENVIRONMENT.  Does this mean that we
    > have to dictate some particular interpreter implementation of
    > COMPILER-LET?  I'm unsure.
    
    I believe so.  It wouldn't work for a user codewalker to bind
    COMPILER-LET variables specially before walking the body, if
    MACROEXPAND-1 is going to look in the environment for variables to
    bind.  (It may mistakenly bind a variable in an outer contour that is
    supposed to be shadowed by one the codewalker bound.)  And it wouldn't
    work for code walkers just to add the bindings to the environment if
    MACROEXPAND-1 doesn't look for them. 
    
    Do you really want to go ahead with this idea?  At the very least, I
    think it would have to be presented as a separate proposal from
    COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
    implement that proposal. 

This should be followed up.  I guess a separate proposal is a good idea.
I think COMPILER-LET-CONFUSION:REPAIR should be split into four proposals.
First, one that gives the general framework for repairing but doesn't
say anything about how the interpreter implements COMPILER-LET, other
than to say that an additional proposal is needed to cover that.  Then
three proposals for how the interpreter implements COMPILER-LET:
 (1) The interpreter always does a "semantic pre-pass" like the compiler.
 (2) The interpreter expands all macros inside COMPILER-LET before
 evaluating any of the code inside COMPILER-LET.
 (3) COMPILER-LET passes the variable bindings to MACROEXPAND-1
 through the lexical environment, and the time when the interpreter
 expands macros is not changed.