[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: PACKAGE-CLUTTER (Version 2)



      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