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

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

    Date: Tue, 14 Mar 89 19:07:31 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 18:41 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    > The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
    > of a MACROLET special form, instead it should be a list of lists (name
    > function).  That is, the expander functions should be supplied in the
    > form of functions rather than in the form of the source text used by
    > MACROLET.  Your rationale argues against this but I strongly believe
    > that the rationale is wrong.  I wouldn't mind seeing the parsing portion
    > of MACROLET made available as a separate function.

    Can you provide a rationale for this?

What if we got here not via looking at a MACROLET in the user's source,
but through some other path that causes us to want to use local macros?
Should we have to take the expander functions in our hand and somehow
turn them back into MACROLET syntax so AUGMENT-ENVIRONMENT can turn them
back into functions again?  It's a simple question of levels of abstraction.

    Actually, I wouldn't object to the change as long as the function to do
    the parsing is provided.  (I speak from personal experience, this is 
    really a hairy piece of code to have to write from scratch.)  

Not if you have DESTRUCTURING-BIND.  But I guess that hasn't been
accepted into the language yet.

    How about
    
      PARSE-MACRO name-and-definition &optional env		[Function]

      Name-and-definition a list of the form (name lambda-list . body),
      as in the format of a MACROLET special form.  Two values are returned:
      the name of the macro and a macro function.
      
It should return a lambda expression, not a function.  Most likely that
is what you really meant to say.  I have a mild preference for passing
the name, lambda-list, and body as separate arguments, and returning
only the function, not the name, but that's not vital.  But I would propose:

  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.  Name is the name of the macro and
  is supplied as an argument for implementation-dependent use, such as
  including the name of the macro in error messages issued if the form
  does not match the lambda-list.

    >   DECLARATION decl-type name &optional env     [Function]
    > 
    >   decl-type is a symbol.  The interpretation of name depends
    >   on decl-type.  If a declaration of that type and name is
    >   in force in the specified environment, it is returned, otherwise
    >   NIL is returned.  The following decl-types are specified,
    >   additional implementation-dependent types could be added:
    > 
    >     INLINE function-name => T or NIL
    >     NOTINLINE function-name => T or NIL
    >     IGNORE variable-name => T or NIL
    >     OPTIMIZE quality => integer
    >     DECLARATION decl-type => T or NIL

    Hmmm.  Could we extend this to handle the TYPE and FTYPE declarations
    too, and dispense with VARIABLE-TYPE and FUNCTION-FTYPE?  

The problem is that the declaration scoping rules require that both
declarations and bindings be examined in parallel to decide whether a
declaration is in force or is shadowed by a binding inside it.  This
applies to TYPE, FTYPE, INLINE, NOTINLINE, SPECIAL, and IGNORE.  I
thought about this for quite some time.  The choice is whether to have
one DECLARATION function that behaves irregularly, using different
scoping rules for different decl-type arguments, or to have separate
functions VARIABLE-TYPE, FUNCTION-FTYPE, FUNCTION-INLINE, VARIABLE-KIND,
and VARIABLE-IGNORED.  FUNCTION-INLINE would return one of NIL, INLINE,
or NOTINLINE.
		       
I hadn't realized the full scope of this problem when I sent my comments
yesterday.  I haven't yet settled on a position that I believe, however
I don't like the proposal as it stands because it offers access to some
declarations but not to others.  I remember an older version of the
proposal had one function for variables and one for functions, and each
returned multiple values which were the complete information about the
variable or function.  What was the criterion for getting rid of that?
It might help decide this issue too.  Can we continue discussing this?

    And, should the symbols for the decl-type argument be keywords?

Absolutely not!  They should be the same symbols that DECLARE uses.

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

I still believe that this way of doing COMPILER-LET is better than
fully expanding all macros whenever the interpreter sees a COMPILER-LET.
But I don't feel very confident in dictating a particular implementation.
Can we continue discussing this?