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

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

This looks good so far.  A few comments that might help you
along with the draft:

VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.

It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".

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.  An implementation that canonicalizes type
declarations would do this.  For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else.  Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way.  If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.

I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".

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.

No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes).  I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff.  The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:

  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

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.

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.

On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.

Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.