[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5



    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.