New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

The return values of ENVIRONMENT-VARIABLE-KIND in this  proposal clashes
with PROCLAIM-LEXICAL in a bad way. I would prefer if it returned at least
two values:

 Value 1 (KIND):
   NIL       = No declared semantics
   LEXICAL   = Lexical variable
   SPECIAL   = Special variable
   MACRO     = Symbol macro

 Value 2 (WHERE-DECLARED):
   GLOBAL    = Globally declared
   LOCAL     = Locally declared
   NIL	     = Not declared

A third value you might consider returning is CONSTANT-P, so that a
variable declared by DEFCONSTANT could be distinguished. You could deal
with this by a separate function, though, similar to ENVIRONMENT-INLINE.

In fact, I also think the returned values (other than T and NIL) should
be keywords because
 - keywords are easier to deal with
 - keywords are safe here (the set is non-extensible)
 - it would be more consistent with other inquiry functions
   like FIND-SYMBOL, which return status info in keyword package.

Your suggested values would map as follows:

 KMP suggestion		EB suggestion

 NIL,     NIL		NIL
 SPECIAL, GLOBAL	PROCLAIM
 SPECIAL, LOCAL		DECLARE
 LEXICAL, LOCAL		T
 MACRO,   LOCAL		SYMBOL-MACROLET

My proposal leaves a few meaningless combinations, but has the virtue of
being extensible for other situations possibly yet to come, such as:

 MACRO,   GLOBAL	Symbol macros (Symbolics Genera has them)
 LEXICAL, GLOBAL	Global lexicals (see issue PROCLAIM-LEXICAL) 

The following other case which exists now but which you didn't address
might be worth considering, too:

 NIL,     GLOBAL      	Reserved words (eg, &FROBOZZ)

I'd also be curious to know why you want ENVIRONMENT-VARIABLE-TYPE to
return NIL in the case where something's undeclared. I propose it return
T (the default type, after all), and perhaps offer a second return value
which says whether the information was declared or defaulted. Actually,
come to think of it, the second return value could be NIL, LEXICAL, or
GLOBAL for consistency with my suggestion above.

Perhaps also ENVIRONMENT-INLINE could return as many as three values:
INLINE-P, INLINE-INFO-AVAILABLE-P, and WHERE-DECLARED
so that you could distinguish global from local information, etc.

The reason I suggest these is that a lot of kind of reasoning could 
be done by looking only at the first value. The way you have all your
functions structured, you have to case for a lot more things than you
might really want to know. eg, if your only interest is to determine
if a variable is going to do a special reference, you have to look 
for two markers (DECLARE and PROCLAIM) under your scheme, but a binary
value under mine. Similarly, if you want to know the type of something,
you have to special-case NIL under your scheme but can just use the
return value directly under mine. Only advanced applications where
more info is needed would need to pick up the additional values. Further,
the additional information is richer than the information provided in
your proposal.

I'll have to talk to our compiler people about the feasibility of some
of your suggestions. I may have more comments on that later.