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

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

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

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.

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

Looking over back mail on this issue, I see that you made a similar
suggestion while we were discussing version 1, but that it was never
incorporated into any later version of the writeup.  It would help me
to understand the issues involved better if you can come up with
something specific on this.

Incidentally, version 1 did include individual accessor functions for
INLINE and OPTIMIZE declarations, plus hooks for dealing with block
names and go tags that are not included in later versions.

> Can we continue discussing this?

Yes, but let's discuss the problems with COMPILER-LET separately.
Neither of the existing COMPILER-LET proposals require anything
special to be done with the environment accessor issue.

-Sandra
-------