Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5

[David N Gray <Gray@DSG.csc.ti.com>]

>  DECLARATION decl-spec &optional env     		[Function]
> 
>   This function returns a list of declaration-specifiers whose CAR
>   is the symbol DECL-SPEC that are in force in the environment ENV,
>   sorted so that the innermost declaration is first on the list.
> 
>   It is required that this function recognize OPTIMIZE and DECLARATION
>   declarations.  The results are unspecified for any other built-in
>   declaration-specifier.

I'm uneasy about the notion of the notion of returning all the
declarations, innermost first.  First, note that since DECLARATION is only
valid in PROCLAIM, there isn't any lexical ordering.  OPTIMIZE
declarations do have lexical shadowing, but is that really relevant?
Don't you just want to know what the current values are, not all the
history of how they got that way?  For example, given

  (defmacro show-opt (&environment e)
    (print (declaration 'optimize e)))
  (proclaim '(optimize (speed 1)))
  (defun ff (x)
    (declare (optimize (space 2)))
    ...
    (dotimes (i n)
      (declare (optimize speed))
      (show-opt)
      ...) ...)

this specification would lead one to expect the value printed to be

  ((OPTIMIZE SPEED) (OPTIMIZE (SPACE 2)) (OPTIMIZE (SPEED 1)))

It should be valid for an implementation to return, for example:

  ((OPTIMIZE (SAFETY 1) (SPACE 2) (SPEED 3)))

because all the compiler cares about or wants to remember are the current
values.  (Any implementation that really uses OPTIMIZE declarations is
going to want to have a more efficient way of accessing them than searching
through a list.  The same thing applies to a macro that wants to use this
information; requiring them to search a list for what they want would
discourage the use of this feature.)  I think I'd rather see

  (DECLARATION 'OPTIMIZE env) => ((quality value)...)
  (DECLARATION 'DECLARATION env => (symbol symbol ...)

Note that this approach makes it much easier to do something like this:

  (let ((save-opt (declaration 'optimize)))
    (proclaim '(optimize ...)) 
    (compile-file ...)
    (proclaim `(optimize . ,save-opt))) ; restore previous values

>	...	Note that if an
>   extended declaration specifier may be "bound", this function should
>   return only those declarations that apply to the lexically visible
>   binding.

The binding of what?  Probably you mean "... that apply to some binding
which is lexically visible"?  I don't think this is feasible -- if binding
declarations are stored in the variable table entry, then it is not
reasonable to be asked for a list of all of them, while if you use a list
as a stack of declarations, then you don't have an easy way to keep track
of which ones are connected to non-shadowed variables.  Better to say that
the DECLARATION function is only for pervasive declarations.

Also, in regard to binding declarations, instead of just saying that
VARIABLE-INFORMATION can return additional values, how about saying that
the fifth value is a property list of implementation-dependent
declaration keys and values?  That way, extensions developed at different
places could later be mixed together rather than necessarily being
mutually incompatible.