A stupid lisp question...

[Jon L White <jonl@lucid.com>]

Lucid's current release -- 3.0 in the Sun world -- permits the addition
of the "proprietary extensions package" to the default use list.  It is
my understanding that TI's 3.0 release also has this feature (but I don't
know whether or not it is out of Beta testing yet).  Several other vendors
have expressed their intent to make the extensions available this way.  
Lucid documents a global (special) variable that holds the default use 
list; I'm not sure about the others.

Some Lisps have, in the past, placed all their extensions in the LISP
package; thus there was no easy way to exclude the proprietary extensions.
Others have only made their extensions available in non-uniform ways;
for example, you may inherit them in the USER package, but not in another
defaultly made package.

The various Common Lisp standardization bodies have often acknowledged
this situation as a problem; but they have never effectively dealt
with it.  Several times during the past four years, there has been a call 
for a universal "package registry", whereby implementations would "
register" the names they use for extensions package; but nothing has 
happend yet.  It has always been expected that the standardized Common 
Lisp would be a portable subset of a vendors "extended" Common Lisp.

It is worth noting that although portability of programs is a Common
Lisp goal, the vast amount of "porting" that actually takes place is
from one release of a vendor's product to another such release.  In
Lucid's case, we also see a lot of porting between our various platforms
(e.g., between the Sun3, the Sun4, VAX/Ultrix and VAX/VMS etc.)  Although
there is some migration of Symbolics 3600 code to Lucid's platforms, the
biggest porting headaches I've heard about are those porting from
Symbolics Release 6 to Release 7.  Given this pattern of portings, the
above mentioned technique -- permitting the :use list default to be
implementation dependent -- gives a slight edge in ease of use to those
who are porting within one family of vendors, without causing any
real known problems for those porting to "pure" Common Lisp.


Incidentally,  your advice to use strings as package names for
IN-PACKAGE commands in preference to symbols is right on the mark.
You might be interested in reading the current proposal for a
DEFPACKAGE form which was recently accepted by the X3J13 group
(the body that is recommending a standard for Common Lisp to ANSI).


-- JonL --