Re: packages and portability

[franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)]

  Our package setup is a bit different than the DEC  proposal described
by Ugo Buy.

 1. The 'lisp' package contains only those external symbols defined by
    the book.   [DEC would call this the common-lisp package.  I could
    see this name change being useful for people with existing lisps
    who want to embed a common lisp into their lisp.  If these people
    come forth and lobby for it, I suppose I'll agree, otherwise I think
    it should continue to be named lisp.]

 2. The 'excl' package contains external symbols which are distinct from
    those of the 'lisp' package, and these symbols represent most of
    our extensions.   We thus agree with DEC that each implementation should
    define an extension package with a unique name.  We don't think that
    the lisp package symbols should be imported  into this package
    (more on this below).
    
 3. If extensions must be made to the functions in the book, (i.e. symbols
    in the lisp package) they are made only where upward compatibility
    is preserved, and it is clearly documented in the manual that these
    are non-portable extensions.  [What I'm talking about are
    things like extra keywords to 'compile-file'.  The list of such extensions
    will always be less than a page].

 4. The 'user' package uses both the 'lisp' and 'excl' packages in the
    version of common lisp we ship.   It is a simple matter to unuse
    the 'excl' package in your init file (or globally for all users)
    if you want a pure common lisp.  [as long as you don't use the
    lisp package function extensions documented it the book]

 5. The default use list for the make-package and in-package functions
    is still the 'lisp' package.   This is important, it makes the user
    identify non-portable code.   It prevents the user from running
    ExCL only code in Vax-Lisp (as soon as the in-package is executed,
    Vax-Lisp will complain about a missing excl package).

In point (2) I mentioned that the excl package doesn't contain the lisp
package symbols.  This permits you to go into extended mode with a
use-package and out of extended mode with unuse-package (in the DEC mode,
the package switch is more complex).  But more important, I think that
our way is 'extensible' to the future when extensions come in their own
package.   In fact right now we have our standard extensions in the 'excl'
package, but we also have a 'foreign-functions' package, two graphics packages,
a flavors package, a 'cross-reference' package, etc.   In our model, you
can simply use the packages you want to work in.  The excl package extensions
aren't treated any differently than the other extensions and I don't see
why they should be.


-john foderaro
 franz inc.