[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 22 Mar 89 11:34 EST
- Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@SAIL.STANFORD.EDU, cperdue@Sun.COM
- In-reply-to: <2815505310-8473304@Kelvin>
Date: Tue, 21 Mar 89 14:48:30 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> DECLARATION decl-spec &optional env [Function]
I'm uneasy about the notion of the notion of returning all the
declarations, innermost first.
That was done so that DECLARATION does not have to have specific
knowledge of how to deal with each different decl-spec; instead
the caller has that knowledge. Otherwise we would have to add
a way for people defining new declarations to tell DECLARATION
how to parse them and how to decide whether an inner one shadows
an outer one.
First, note that since DECLARATION is only
valid in PROCLAIM, there isn't any lexical ordering.
The proposal should say that the order of proclamations is most recent
first.
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?
Of course. The issue is whether that knowledge, which is specific to
the format of the OPTIMIZE declaration, goes inside of the DECLARATION
function or goes in the caller of the DECLARATION function.
I think I'd rather see
(DECLARATION 'OPTIMIZE env) => ((quality value)...)
(DECLARATION 'DECLARATION env => (symbol symbol ...)
That was what I originally proposed, so I'd rather see it too. (Except
I also proposed an additional <name> argument, which was the quality for
OPTIMIZE, the decl-spec for DECLARATION, something else for other
declarations, in some cases ignored.) The problem is that it is not
extensible without designing another mechanism that nobody wanted to
think about right now to tell DECLARATION how to parse the declarations.
Maybe we made a wrong choice here. Do you want to propose the details
of that mechanism?
Better to say that
the DECLARATION function is only for pervasive declarations.
That would be okay with me. I'm not sure "pervasive" is the correct word,
though; I assume you mean that the DECLARATION function is only for
"declarations that do not concern themselves with variable or function
bindings".
BTW I still think DECLARATION-INFORMATION might be a better name than
DECLARATION.
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.
That's a good idea. In fact I think IGNORE should be on that property
list rather than being a separate value, since it's so miscellaneous.