Issue: PROCLAIM-LEXICAL

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

Sorry, I hit the wrong key and shot that last message off before I was
done editing... 

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 that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users.  Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".

        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 legal Common Lisp, and this is one of those
things.  So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.

So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.

-- Scott