Issue: LISP-SYMBOL-REDEFINITION (?)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 27 Sep 88 23:15:16 PDT
    From: 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.

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

I didn't say anything about property lists. Property lists are safe as long
both the symbol and the indicator aren't global. Either of
 (GET 'LISP:xxx 'PRIVATE:xxx)
and 
 (GET 'PRIVATE:xxx 'LISP:xxx)
is safe.

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

That's why I mentioned "types" above. I don't think you should have a 
pre-defined type by this name, but not everyone puts types on the plist.

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

Right.