Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

Just to respond to a few of the points you raised in your message:

AUGMENT-ENVIRONMENT is intended to be used by program analysis
programs, not to add things to the environment in macro functions just
for the heck of it.  I'd say that any macro expander that tries to add
things to the environment that aren't really there is broken, because
it doesn't "preserve semantics" of the macro call.  There are lots of
other ways users can get into trouble with macros that don't have
anything to do with environments, but I don't think the standard is
going to address that problem.

The reason why it's necessary to put some information about variable
and function bindings in the environment, even though the actual
bindings are not fully defined, is so that they will shadow macro
definitions or global definitions of those variables and functions.
For instance, binding a local function named FOO shadows any macro
definition of FOO in an outer contour.

Code walkers have to pick apart forms like LET and LABELS anyway
(because the initial binding forms and local function definitions have
to be walked in the appropriate environment), so there isn't much
motivation for making the corresponding inputs to AUGMENT-ENVIRONMENT
syntactically identical.  All you need is a call to (MAPCAR #'CAR ...)
to extract the right information, anyway.  Your suggestion for
WALK-INTO won't work for the same reason -- it would have to walk the
parts of the form that establish the initial values for the bindings,
as well as the body.  Also, I've experimented in the past with trying
to write a generic code-walker that used hook functions like you
suggest, and found that it didn't work very well.  It didn't give
enough control over the right kinds of information.

-Sandra
-------