Re: Packages: where is the beef ?

[tony@brc.uconn.edu (Tony Guzzi (Staff))]

### From: simon@lia.di.epfl.ch (Simon Leinen)
### Date: Thu, 3 Sep 92 21:26 MDT
### Cc: allegro-cl@ucbvax.berkeley.edu, ks@cs.tut.fi
### Subject: Re:  Packages: where is the beef ?

### > with Artifical Intelligence-oriented people (like myself) using lisp
### > very often (and defining classes and trees in thier work all the
### > time), the choice of system-important symbols like these was highly
### > inappropriate.  What were the people in the CommonLisp standard
### > committee (X3J13) thinking of???
###
### ASSERT and CLASS are symbols that are intended to be used by users
### (programmers in this case).  It is a *feature* that they have intuitive
### names.  It is also a problem that X3J13 defines 973 of these symbols,
### and nobody can be expected to know all of them.  Allegro's package-locking
### is another *feature* that prevents you from breaking the system because
### you don't know all of them.

ONE EDIT (to clearify what I meant):
### > time), the choice of *EXPORTED* system-important symbols ......

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.

RE: new naming convention
### Completely unnecessary - *everything* you can do with funny naming
### conventions you can do (better) with packages.

True, EXCEPT (I believe) in the case of *exported* symbols.  Once exported
and inherited by another package, all the protection offered by packages is
gone.

### > ..... This is the type of thing many compilers (C, FORTRAN, Pascal) do
### > to safeguard internal functions (the most common technique being to add
### > a '_' to the beginning and/or end of the symbol/variable/function_name.
###
### External symbols in the C libraries have very much the same problem
### than the symbols that are exported from the COMMON-LISP package. .....
### C's workaround for this problem is to choose obnoxious names for library
### functions, or use separate libraries, much like there are separate
### packages in CL.

(FOR ALL OF THOSE WHO POINTED THIS OUT, ...)
Ooops, my error.  (I tested it and you're right; I had assumed the linker
would would be smarter and give a "redefinition" warning message [as it turns
out similar to ACL's error message from the package-locking mechanism].)

That side, it's still the case that by using "obnoxious names", they have
decreased the chances of someone _accidentally_ redefining them and with it,
the need for a facility similar to the package-locking mechanism.  For
example, 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.

### > X3J13 needs to redefine a few _important_ symbols, I think, to make
### > them less susceptible to user-'munging' yet still accessible if in
### > the hands of knowledgable (i.e. 'know what they're doing')
### > programmers.
###
### That's not been X3J13's task.  I don't think friendliness to students
### would have been a reasonable goal for a CL standard - .....

Students are only an extreme case of the 'naive user', but they do illustrate
my point.  However, I do believe X3J13 should have taken the steps necessary
to safe-guarded important _exported_ symbols (like 'CLASS' in CLOS and 'TREE'
in Top-Level which are in turn is exported by COMMON-LISP to all packages
which don't explicitly use some other package and *don't* ':use' the
COMMON-LISP package).  ACL's use of CLOS to implement the I/O subsystem is a
good example of how this situation can lead to a domino effect involving
seemingly unrelated systems.  If you accidentally clobber one subsystem (CLOS
in this case), you also clobber what would initially appears to be an entirely
unrelated subsystem (the I/O subsystem here; it uses CLOS).

### > The only solution I've found is to shadow the symbols in the package. 
###
### Of course this works.  It is only that very few people know how or dare
### to use shadow.  I know that because in our AI lab people rarely even
### use packages at all, and we're a 100% Common Lisp shop.  What a shame.

I'm also a little uneasy abouting shadowing too, but when you have a couple of
megabytes of CLTL-1-complient source code which contain a number of packages
which define local 'class' and 'tree' structures and don't have the time or
background to edit the files (they were FTP'ed from another site), you take
your chances.

### The package system is your friend.
### Allegro's package locking is your friend, too.

As I said in the beginning, I agree with you on both counts.  But I think a
little more care should have been taken when it came to choosing some of
the more critical symbols (from the Lisp system operations point of view)
that are exported and inheritted [via the COMMON-LISP package] by most other
packages.

-- Tony Guzzi
   (graduate student)

 Internet:		| U.S. Mail:
    tony@brc.uconn.edu  |    University of Connecticut
			|    U-155, Dept. of Computer Science & Engineering
			|    260 Glenbrook Road
			|    Storrs, CT  06269-3155