[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PACKAGE-CLUTTER (Version 2)
- To: masinter.pa@Xerox.COM
- Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
- From: Scott.Fahlman@B.GP.CS.CMU.EDU
- Date: Fri, 23 Sep 88 10:06:14 EDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Your message of 23 Sep 88 01:15:00 -0700. <880923-011503-3968@Xerox>
Those symbols with function, variable, macro, setf, constant definitions
or uses as properties or tokens may have no other additional definitions
other than those specified.
...
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it may
not be bound, defined as a type, or defined as a function, macro or
special form.
...
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
Where did this come from? I am vehemently opposed to this, if you intend
this restriction to apply to users as well as to implementors. We've got a
language that, for better or worse, has separate namespaces for functions
and variables, and additional namespaces for properties and flags of
various kinds. Just because Lisp pre-empts the use of some symbol as a
function name does not mean that users should be prevented from using it as
a variable name or marker in a property list.
If we impose this restriction now, we are creating a very large "cost of
adoption". Just as one example, every user program that uses LIST or
SYMBOL or MEMBER as a local variable will have to be altered.
If we want to say anything along these lines, we should say that
*implementors* must not use these exposed symbols in additional,
undocumented ways within their implementations, since users can get hold of
these symbols and use them in conflicting ways.
-- Scott