Issue: PROCLAIM-LEXICAL

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

        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).

OK, I think we agree here, more or less.  I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers.  Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".

        The second problem is Moon's suggestion that it should be an error to
        assign or reference an unproclaimed and undeclared variable.  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?

Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs.  That's our main concern,
but not our only one.  I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them.  So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)

 this issue doesn't affect portable
programs, but that's not the only concern we should deal with.  I would
like to see 

        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.