packages and portability

["BACH::BUY" <buy%bach.decnet@hudson.dec.com>]

It seems that my previous message was mistankenly sent three times to
the mailing list and I would like to apologize for any confusion that
that may have caused. I will make sure only one copy of this message
is mailed out.

This is in reply to John Foderaro's message about the package
configuration adopted by Franz for their implementation of Common
LISP. A number of points were brought up evidencing differences
between the DEC proposed configuration and the Franz configuration. 


>  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).
>...
>
>  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]
> ...
>
> 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.

I agree about the fact that the uniformity of your package model is
indeed appealing, however this model may prove inconvenient to use in
the case of symbols that have two distinct definitions, one each in
the pure Common LISP and in the extended package. In fact, I think
that a desirable feature of the future package configuration is not
to preclude the possibility for a symbol to be defined in both the
pure Common LISP and the extended package. According to your model,
in the case of symbols defined in both packages, the creation of an
extended environment (similar to the USER package) always results
into name conflicts, unless shadowing is used, which may be tedious
to do.

Furthermore, the resolution of a name conflict between two external
symbols inherited by the using package may cause one of the two
symbols to be imported (CLtL p. 180), which will render such a symbol
insensitive to subsequent UNUSE-PACKAGE operations (CLtL p.177). So,
should name conflicts caused by (USE-PACKAGE 'excl) be resolved in
favor of the extended symbols, subsequent (UNUSE-PACKAGE 'excl) will
not get rid of the extended definitions for such symbols. The model
we proposed can deal uniformly and (relatively conveniently) with
symbols defined in one or both of the two packages. To switch from an
entended to a pure Common LISP environment:

	(UNUSE-PACKAGE 'VAX-LISP)
	(COMMON-LISP:USE-PACKAGE 'COMMON-LISP)

Viceversa, to switch from a Common LISP to an extended environment:

	(UNUSE-PACKAGE 'COMMON-LISP)
	(COMMON-LISP:USE-PACKAGE 'VAXLISP)

In addition, it is not immediately obvious to me that the package
name EXCL is going to be exclusively used by Franz: it sounds like an
acronym for extended Common LISP and may therefore be used by
multiple implementations.

    
>  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].


I agree that extensions to white page objects should be upward
compatible, however I don't think it is possible to establish a fixed
upper bound on such extensions and on the amount of documentation
for each of the extensions (e.g. the VAX LISP User Guide
documentation for COMPILE-FILE is three pages long). Also, site
specific extensions to white page objects should be stated to be
non-portable in the on-line documentation as well. In summary, I
think that the most reliable way to deal with white page extended
objects is to provide two distinct definitions, one for each of the
two packages. Although double definitions may not appear to be
necessary for the time being and may be tedious to implement, I think
that they should not be precluded a priori from future
implementations. 


				Ugo Buy
				
				ARPAnet:  BUY%BARTOK.DEC@DECWRL.ARPA




------