[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
- To: Sandra J Loosemore <email@example.com>
- Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 20 Mar 89 16:39 EST
- Cc: cl-compiler@SAIL.STANFORD.EDU
- In-reply-to: <8903151840.AA04690@defun.utah.edu>
Date: Wed, 15 Mar 89 11:40:35 MST
From: firstname.lastname@example.org (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:
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
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
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.