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

[Darrell: Re: [spr4535] a simple question ]



>>    Why is the symbol VARIABLE exported from the common-lisp package?
>>    I didn't see a reference to the symbol VARIABLE in CLtL 2.
>> 
>> It's pretty well hidden: Check out the second argument to the
>> DOCUMENTATION function, CLtL2 p.695.  The legal values are VARIABLE,
>> STRUCTURE, TYPE, FUNCTION, SETF and METHOD-COMBINATION (see the CLOS
>> chapter).  The first two of these symbols are exported from the
>> common-lisp package for the sole purpose of the DOCUMENTATION
>> function, but all the others have other uses.

To those who answered me, thank you.  I mistakenly assumed that CLtL 2
has an index entry for every symbol used.

On a more general note, I would like to discuss the package mechanism.  
A symbol has various usages; it can be used simply as an identifier 
(as in the case mentioned above) or to name a variable, function, 
structure, class, property list, etc.  For brevity, a symbol's "critical 
usages" are as a variable name or as a function name.  Similarly, a 
symbol is "critically used" if either its value cell or function cell 
is bound.  

As Steele states, by exporting a symbol from a package, a statement is 
being made about program structure.  I am wondering if the package 
mechanism is robust enough, or is it over-kill for a package to reserve 
the critical usages of all its exported symbols?  In the aforementioned 
example, the symbol VARIABLE's only usage, in the common-lisp package, is 
as an identifier; it serves no other purpose.  However, because the symbol 
is exported and the common-lisp package is locked, it is an error for another 
package to critically use that symbol (i.e., it is an error for another 
package to use the symbol variable as either the name of a variable or a 
function).  My personal feeling is that an export'ed symbol should be 
specific to usage.  Thus, only the VARIABLE's identifier usage should be 
exported from the common-lisp package.  While I have not given enough 
thought to implementation issues, it appears do'able.

Any thoughts? 

Thanks,
Darrell Shane