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

[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>
> 
> I would assume that VARIABLE-TYPE is not required to return the
> exact declared type specifier, but could return another type
> specifier that is equivalent, or possibly another type specifier
> that is a supertype.

That sounds reasonable to me.

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

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.)  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.
      
>   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?  And, should
the symbols for the decl-type argument be keywords?

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

-Sandra
-------