Re: [spr4535] a simple question

[smh@franz.com (Steve Haflich)]

   Thanks for your reply.  I would have expected the CLtL 2's index to 
   have an entry for the symbol.  Why isn't the second argument to 
   documentation a keyword?  

Guy admits to having integrated X3J13 changes into CLtL2 rather
quickly, without doing all the rewriting and cross indexing he would
have liked to have done, so failures of indexing are to be expected.
Kent Pitman put together a complete machine-readable list of all
lisp-package symbols and their uses as an aid while working on the
ANSI draft.  This is available by public ftp (I think from
arisia.xerox.com) but it's pretty dry reading.

There is no particular reason the argument couldn't have been a
keyword except for parallelism with the other symbols such as FUNCTION
which do have other meanings in the CL package.  They all could have
been keywords, of course, but this would have caused minor but
unnecessary back-compatibility problems.

   My question stems from a problem I am having porting a working system 
   from 3.1 + PCL to 4.1b.  There are a number of classes which define a 
   slot accessor variable.  However, in 4.1b this generates an error due 
   to a package locking mechanism.  Is there some documentation which 
   describes package locking?  why not allow a symbol's value cell or 
   function cell to be set if it was unbound initially?

It's really very simple: As you point out, there would certainly be no
problem if a wise experienced, intelligent, careful, Lisp guru uses
the variable or function binding of a symbol that is not otherwise
used by the language.  The problem comes when some other incompetent,
lazy, ignorant, and just plain stupid hacker TRIES TO DO EXACTLY THE
SAME THING!  (I'm sure you get the point. ;-) The CLtL2 prohibitions
are a recognition that many modules and packages may be loaded into a
single lisp environment, and they all not only have to stay out of the
way of the base language implementation, they also have to stay out of
each other's way.

A description of package locking will be in the documentation with 4.1
final.  Basically, it implements most of the prohibitions in CLtL2
pp.259ff.  You can turn off the errors by wrapping the offending code
with the EXCL:WITHOUT-PACKAGE-LOCKS macro, but in the long term you
are probably better off conforming with the language spec, in the
interest of portability.