[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LISP-SYMBOL-REDEFINITION (?)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: LISP-SYMBOL-REDEFINITION (?)
- From: Jon L White <firstname.lastname@example.org>
- Date: Tue, 27 Sep 88 23:15:16 PDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Kent M Pitman's message of Tue, 27 Sep 88 13:04 EDT <880927130442.2.KMP@GRYPHON.SCRC.Symbolics.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 --