Packages: where is the beef ?

[collins@aspen.serc.3m.com (John Collins)]

Tony Guzzi writes -

   <discussion of name-collision problems deleted ...>

   Let me say right off the bat that I think Allegro's package-locking
   mechanism was a great idea.  I have no problem with.  And, you're right,
   with 973 symbols, noone can be expected to know them all.  My problem is
   with *exported/inheritted* symbols that:
      a) are commonly used, single words [e.g. CLASS, TREE, ASSERT] that are
	 not immediately recognized as possibly being Lisp-system-related
	 [e.g.  LIST, ATOM, CAR, CDR, APPEND, DEFUN, DEFSTRUCT, TOP-LEVEL]
      b) when accidentally `stepped on', can blow a vital part of the system
	 (such as I/O or the top-level) clean out of the water.
   Adding a little boiler-plate (such as the addition of punctuation) to an
   _exported_ symbol that an entire subsystem (package?) depends on would seem
   prudent.

   ### > I think a better decision would have been to use 'unusual' symbols
   ### > (e.g.  '_TREE_' or '!_TREE_!' in the Top-Level package or
   ### > '_<<CLASS>>_' or '<SSALC>' in CLOS instead of just 'TREE' or
   ### > 'CLASS') for highly important symbols to minimize the possibility
   ### > that a user will accidentally re-define them. .....
   ###
   ### Common Lisp's way to handle *internal* symbols is more elegant - ....
   ### No need for underscores.

   True, I only meant to addressing exported symbols, not internal
   symbols.
   ...

   consider how many times you choose a variable or function name that
   is simply a standard word or phrase (e.g. 'ASSERT' [a common
   theorem prover word] or 'CLASS-NAME' [a common classifier system
   type word]) as opposed to something containing punctuation (e.g.
   '!ASSERT!' or '<CLASS>-name').  When it comes to _exported_ symbols
   which a package/system depends very heavily on (such as 'CLASS' in
   CLOS and 'TREE' in Top-Level), a little added protection can go a
   long way.

TREE is not an exported symbol in my copy of ACL.  As for the others,
I have occasionally run into name conflicts with the language, but I
like the fact that the names of things in Lisp are easy to remember.
Part of the basic philosophy of the language is that it is an
extensible language.  That means that the functions, macros, classes,
etc. that I define are *part of the language* once they are defined.
I would not like the predefined parts of the language I use for
problem-solving to look fundamentally different than the parts I add.

To avoid potential conflicts with parts of the language or
implementation I am not using or not aware of, I ALWAYS work in my own
package, not in COMMON-LISP-USER, and when I introduce a new person to
Lisp I get them started that way as well.  I usually don't worry about
conflicts until they show up, and then I decide whether to shadow the
symbol or change my version to a different name.  The only problem
with shadowing symbols I don't think I'm using (I use grep to find
out) is that sometimes macro expansions will generate calls to
unexpected things.  That's when you run into errors that won't print
out or breaks in the break handler.  I try to avoid these problems as
much as possible by not shadowing symbols that seem to be part of the
I/O subsystem or other core parts of the language.

If you are trying to run some old code that doesn't use CLOS, you
should be able to make a package that doesn't use any other packages,
explicitly import the symbols from COMMON-LISP that you really want,
and then inherit from that package into the rest of your subsystem.
You should be able to generate that list of symbols automatically.  Of
course, you can always use the *symbols*, the only problem is with
their *definitions*.  For example, CLASS has neither a value nor a
function binding; its only standard use is that it names a class.  You
just can't have another class (or structure) named CLASS unless you
shadow COMMON-LISP:CLASS.  The DESCRIBE function tells you what
aspects of a symbol are in use for what purpose.

I guess the upshot of all this is that I understand the frustration
you feel with trying to use old code in what is essentially a new
language, but I don't agree with you on the solution.  I think the
language as defined has a strong overall design philosophy that I
agree with.  Implementors could (and I think most do) avoid problems
with macro expansions in packages that don't import the normal
complement of symbols by qualifying every symbol they use with the
package name.

------------------------------------------------------------------------
     John Collins			Phone: +1 (612) 736 0778
     3M Company				FAX:   +1 (612) 733 2165
     3M Center, Building 260-6A-08	Internet: jecollins@mmm.com
     St. Paul, MN  55144-1000		   or     jcollins@cs.umn.edu
------------------------------------------------------------------------