issue SYNTACTIC-ENVIRONMENT-ACCESS

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

I wasn't sure if you expected to hear from me again on this one,
but just in case you did, here are a few brief comments.

    Date: Sat, 18 Mar 89 10:06:16 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Let's try to reach closure on this issue so I can get another draft
    circulated before the meeting.  Here is a summary of what I think has
    happened since the last version was mailed out....

All agreed.

    The remaining issue is still troublesome:

    * We need some way to access other kinds of declarations, particularly
      INLINE/NOTINLINE, IGNORE, and OPTIMIZE.

    I see three possible solutions to this:

    (1) Add a DECLARATION function:

	DECLARATION decl-type name &optional env     [Function]

    (2) Add individual accessor functions for each declaration:

	VARIABLE-DECLARED-IGNORE name &optional env	 [Function]
	FUNCTION-DECLARED-INLINE name &optional env  [Function]
	OPTIMIZE-LEVEL quality &optional env	 [Function]

    (3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
	into a single function, VARIABLE-INFORMATION, that returns
	four values:
    
	- what the current proposal says VARIABLE-KIND returns.
	- a local-p boolean to indicate whether the binding is local or global
	- a type specifier as for VARIABLE-TYPE
	- an ignore-p boolean to indicate whether the variable has been
	  declared IGNORE.

       Similarly, FUNCTION-KIND, FUNCTION-FTYPE, and FUNCTION-DECLARED-INLINE
       would be merged into FUNCTION-INFORMATION.

       Add the OPTIMIZE-LEVEL function.

    Personally, I like option #3 best.  How about the rest of you?

I think the VARIABLE-INFORMATION and FUNCTION-INFORMATION parts of
option #3, combined with some form of option #1 for the other
declarations would suit me best.  If we have to, deciding that
declarations in general are too hard and just putting something
special in for OPTIMIZE would be acceptable, but not as nice.

I checked CLtL and the word is "declaration specifier" rather than
"declaration type" or "declaration kind".  I should have checked
CLtL before I first proposed the DECLARATION function, sorry.

    Date: Sun, 19 Mar 89 13:46:38 PST
    From: cperdue@Sun.COM (Cris Perdue)

    The language permits implementation-dependent declaration types,
    so I think we want to define accessors that can also be extended
    by implementations.

But the language also permits user-defined declaration specifiers via
the DECLARATION proclamation, and if this is to be real the user (not
the implementation) should be able to define declaration accessors.  The
simplest answer is to say that's too far-out and we're not going to
standardize it now.  The most comprehensive answer is some kind of
DEFDECLARATION that allows user control over the parsing, scoping, and
indexing of declarations, powerful enough so all the built-in
declaration specifiers could have been defined with it.  An
intermediate position would be just enough to handle the miscellaneous
declarations seen in current practice, but not general enough to take
over from e.g. VARIABLE-INFORMATION.  See suggestion below.

If done right, this will be another way to replace COMPILER-LET.
That is, information from an outer macro can be passed down to
an inner macro by encoding it in a declaration of a user-defined
declaration specifier.

    ....I think we would want to explicitly
    permit implementations to add more return values to return information
    about implementation-dependent declarations.

Agreed.  That can be done with the stroke of a pen.

    Date: Mon, 20 Mar 89 10:21:47 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    The problem I have with option 1 (adding a DECLARATION function to
    access declarations) is that declarations don't have a regular syntax,
    and that "decl-type" and "name" arguments might not be appropriate for
    expressing the syntax of implementation-specific declarations.  For
    example, several implementations support declarations that control
    global attributes (like downward-only closures or suppressing style
    warnings) that aren't associated with any "name".  

These are easy, the name can just be ignored for these declaration
specifiers.  But see suggestion below.

						       Even more peculiar
    would be something like the declaration Lucid supports that lets you
    say that any objects of a given type really belong to a more specific
    type (such as that all numbers will be fixnums).

This is more interesting; the "given type" can be the name, but maybe the
declaration lookup has to use the (nonexistent) function EQUAL-TYPEP
to compare the name for this declaration specifier?

Another approach would be for (DECLARATION declaration-specifier env)
to return a list of all decl-specs currently in force with the symbol
declaration-specifier in their car, sorted so the innermost declaration
is first on the list.  It's then up to the caller to parse this in
whatever way is appropriate for the particular declaration-specifier.
This is crude but makes it possible to get the job done.  Also this
should say that the results are unspecified (-not- undefined!) if
declaration-specifier is any built-in declaration-specifier other
than OPTIMIZE, so that implementations don't have to be able to
reproduce things like type declarations in their original form.
For implementation-dependent declaration-specifiers, require that
either DECLARATION works or the implementation provides an accessor
that is specialized for that declaration-specifier.