package problems

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

There are a number of issues raised by this recent interchange of mail.
Let me try to touch on a few of them...  Hopefully if I've omitted some,
someone else on SLUG can pick up from here.

Before anything else, let me say that the root of the problem is version
skew at several different levels.  The first is that there are several
base documents against which vendors have attempted to align their
documents:  CLtL1 (a de facto standard), CLtL2 (a non-standard but
widely available document), and the working drafts of `emerging ANSI CL'. 
The second is individual releases of a given vendor's software.  Getting
things right in the face of multiple perceived standards, multiple
vendors, and multiple releases per vendor is very tricky.

The DEFPACKAGE in SCL which is causing Robin trouble is not the ANSI 
DEFPACKAGE but rather an extension to CLtL1 which predates that definition.
In general, Symbolics has opted to `cons' new implementations of Lisp
rather than to `rplacd' old implementations, so we have not incompatibly
changed SCL:DEFPACKAGE just because ANSI's COMMON-LISP:DEFPACKAGE will
behave differently.  So the first lesson is that you should never assume
that just because a name is the same in two different dialects, that the
semantics will be the same.  SCL:DEFPACKAGE is doing just what it always
has, and is not buggy.  It just isn't the DEFPACKAGE that Robin is looking for.
(Most other vendors prefer to incompatibly change their definitions with each
release; we simultaneously support old dialects, like Zetalisp, along
with new ones, like the various Common Lisp dialects.  This difference can
be confusing to some.)

In the `development' system (our next release--Genera 8.3) that I'm
running, FUTURE-COMMON-LISP:DEFPACKAGE does implement the options
specified by draft ANSI CL.  However, Robin is using Genera 8.0, which
by now is pretty old--most customers are using Genera 8.1 (except those
who have the newly announced NXP1000, which has a special NXP-only
Genera 8.2 release).  I don't know if FUTURE-COMMON-LISP:DEFPACKAGE was
implemented in Genera 8.0.

By the way, SCL's DEFPACKAGE has an equivalent option, which looks like
(:SHADOWING-IMPORT CLOS:SETF CLOS:DOCUMENTATION) rather than
(:SHADOWING-IMPORT-FROM "CLOS" "SETF" "DOCUMENTATION").  If it suits
your need, that's an option to consider.

However, in general, one should not use things which are not documented,
and I'm pretty sure that even now, FUTURE-COMMON-LISP:DEFPACKAGE is not
documented.  

Unfortunately, for the near term, even fixing this problem for Genera by 
using FUTURE-COMMON-LISP:DEFPACKAGE would only be setting up to lose in some
other implementation.  Until all vendors are providing the draft ANSI CL
primitives, you are probably better off with CLtL1 technology.  There are
more modern ways to say a lot of this (e.g., there is a better set of EVAL-WHEN
keywords in draft ANSI CL), but each `more modern' way to do things risks 
portability trouble at the current time, so I'd steer clear:

(eval-when (eval compile load)
  (unless (find-package "ALP-CLOS")
    (let ((package (make-package "ALP-CLOS" :use '())))
      (shadowing-import '(clos:setf clos:documentation) package)
      (use-package '("LISP" "CLOS") package))))

Note that the exact contents of the CLOS package is a slight portability
problem, too.  For example, CLASS-PROTOTYPE is not one of the operators
specified by draft ANSI CL, so will not be found in FUTURE-COMMON-LISP, but
is present as an exported symbol of the CLOS package.  If you want this symbol,
keep in mind that it might not be available in all implementations.  It is part
of the MOP, and the MOP is not a standard part of draft ANSI CL.

Note, too, the ANSI-Common-Lisp syntax and the use of the FCL-USER
package are -not- documented.  This is for a good reason: they are not
complete.  This means that part of the functionality there will work
and part of it will not.  We have documented the parts that will: CLOS,
CONDITIONS, LOOP, and SETF.  The other parts are either unimplemented,
implemented but useless in isolation, or not conforming (e.g., parts of
CLtL1-style implementation shows through but does not conform to a revised
specification).  This is a veritable minefield and we are not comfortable
about telling users they should be using it for serious applications.

In my opinion, the -only people who should consider using them are people who
 (a) just want to play around and don't care if things seem to not work.
 (b) don't care if they call up support with problems and get told
     that the tools they are using are unsupported and that we can't
     help them.
Anyone who is going to do serious work for which they expect support under
their Symbolics maintenance contract should prefer to use documented tools, 
which means contriving a package in just the way I suggested above.

Obviously, we look -anxiously- forward to the time when we can announce
more complete support for ANSI CL.  We hate recommending that people use
old-style technology, and we've done a lot of work on ANSI CL since Genera 8.1.
But since what is out there now in the released system is not complete, 
we want to avoid the confusion and bad feelings that will result if customers
begin prematurely to use FCL-USER and ANSI-Common-Lisp syntax and then
find themselves in a bind because it doesn't perform up to expectations. 
So please, Craig and others, don't recommend this to your friends without 
a properly stern warning about the associated support issues, or you do them
-no- favor.

I know this has been kind of a downer message since I'm mostly talking
about things you shouldn't do rather than things you should...  but I hope
these remarks will help avoid confusion down the road, and will therefore
ultimately be seen as constructive.