Issue: LISP-SYMBOL-REDEFINITION (?)

[Jon L White <jonl@lucid.com>]

re: How would you feel about something like the following. It's
    broader, but still tries to be specific...
     Symbols on the LISP package may have function or macro
     definitions, variable definitions or SPECIAL proclamations, or
     type definitions only if explicitly permitted in the specification.
     Neither users nor implementors are permitted to add new kinds of
     definitions for these symbols.

Uncomfortable with the part that says that user's can't use LISP
package symbols for names.  I very much agree that vendors (and VAR's 
like Intellicorp!!!) should not have any definitions "hanging off"
LISP symbols other than the mandated ones.  However, this may spell 
a bit of work for implementations like VAXLISP that use the property 
list for compiler internals.

In fact, at one point in time, some of Lucid's window tool kit
implementation "leaked over" into the Lisp package; the symbol
POSITION had some random defstruct about it; and when a user
tried his own defstruct, he was overly surprised to see that 
the system depended on that one [the windows package simply
forgot to shadow POSITION].

Jim Boyce here at Lucid has taken an interest in this matter; I'd
like to get him to write out a full critique, and possibly a new
proposal.  In particular, he points out that we should also constrain
implementors from depending on the *lack* of any additional 
definitions other than the CLtL ones.  Can you imagine a vendor
selling a Lisp that _dies_ as soon as you do (defvar list 3)?


-- JonL --