Issue: PROCLAIM-LEXICAL

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

    Date: Sun, 17 May 1987  17:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

I think I forgot to answer this, but if you're seeing it twice, I apologize.

    I think that Moon's analysis of this issue is right on the mark, and I
    like his proposal 

Thanks.
		      except for two points:

    First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
    DYNAMIC 

CONSTANT, you mean.

	    can be in effect for a variable at any one time, but the
    proposal does not address the question of whether you can over-ride an
    old proclamation in this set by issuing a new one.  We have to address
    that, I think, and it is a moderately complex question.

I think this is an environment issue rather than a language issue.

    ....
    If Rob's compiler proposal, or something like it, were in effect, we
    could probably explain what the rules are within that framework.

I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
that Lisp.

    However, given the current state of things, it might be best to say that
    it "is an error" to re-proclaim a variable into a different class --
    this says that portable code cannot do this and count on the result --
    but that implementations are strongly urged to allow this
    re-proclamation as a way of correcting erroneous proclamations, perhaps
    issuing a warning or signalling a correctable error whenever a
    proclamation actually gets changed.

In other words, it's an environment issue.  I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).

    The second problem is Moon's suggestion that it should be an error to
    assign or reference an unproclaimed and undeclared variable.  

Actually I just copied that from Rees.

								  The
    problem I have with this is that most of us like to be able to do things
    with undeclared variables in the interpreter -- stashing things in
    made-up variables like FOO -- and I think that there will be blood in
    the streets if we take this away from people or if the interpreter is
    required to hassle them for not declaring the variable before using it.

That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?

    And yet, when the compiler comes across an undeclared variable, I want
    to get a warning, especially now that I can use a LEXICAL proclamation
    to flush that warning with no other side effects.

    I think that the right move is to say that accessing and referencing an
    undeclared variable is legal, and that such references access the global
    cell while leaving the variable in unproclaimed state.  We should then
    encourage (require?) compiler writers to issue a warning in such cases.

That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.

    Of course, if you believe that the compiler has no business warning
    about anything that is technically legal (and some wording in Moon's
    "cost of adoption" section suggests to me that he may be in this camp),
    then the above proposal is a non-sequitur.  In my view, however, the
    compiler may issue a warning about code that is legal but suspicious,
    though I agree with Rees that in all such cases there should be
    something you can put in a program to say, "Shut up, I know what I'm
    doing here."  The LEXICAL proclamation gives us that.

True.