packages and portability

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

This note relates to the discussion about packages and portability
that recently took place in this digest. The major focus of the
discussion has been the definition of a mutually agreed-upon package
configuration to suitably support the portability of Common LISP
programs across different implementations. This issue is currently
under investigation by the VAX LISP development group here at DEC and
we would like to present our viewpoint on the subject.

Although many different suggestions have been made during this
discussion, it appears that an agreement was reached on a number
of points. Here are some of the points:

1. Symbols denoting Common LISP defined objects should be contained
   in a pure Common LISP package. These symbols are owned and
   external in this package and no other external symbols should
   appear in this package. So far, most participants in the
   discussion appear to have agreed that the name of this package
   should be LISP.

2. Symbols denoting implementation specific language extensions
   should be contained in a separate package. Such a package may or
   may not use the package containing pure Common LISP definitions.

Based on these points, we would like to propose the following outline
for the package configuration of future releases of VAX LISP:

1. Two packages are used: one to contain external symbols denoting
   pure Common LISP definitions, the other to contain external
   symbols denoting both pure Common LISP definitions and VAX LISP
   specific definitions.

2. The default environment (i.e. the USER package) uses the extended
   package (i.e. the package containing symbols both for pure Common
   LISP and for VAX LISP specific definitions).

3. The default :USE arguments to MAKE-PACKAGE and IN-PACKAGE are also
   the extended package.

A first observation about the naming of the above mentioned packages
is in order. Although some agreement was reached on LISP being the
name of the pure Common LISP package, we believe that a more specific
name, such as COMMON-LISP, is probably more appropriate. This is
because the name COMMON-LISP better captures the desired semantics
of this package, that is, to contain only the Common LISP subset of a
LISP implementation. We obviously recognize the benefits of adopting
a standard name for this package and are therefore open to discussion
about this issue. As far as the extension package is concerned, the
name VAX-LISP is our preferred choice for the same reason as the name
COMMON-LISP for the previous package. Notice that this proposal
contradicts the specifications in CLtL, in that no provision is made
for a package named LISP (p. 181). However, we believe that the spec
of the LISP package in CLtL is ambiguous and should be modified in
any case, because it does not indicate whether LISP should contain
just the Common LISP subset or the implementation specific extensions
as well. Moreover, this scheme leaves each site using VAX LISP the
freedom to use the name LISP as a nickname for either the pure Common
LISP or the extended package. Although we do not advocate the use of
the package name LISP in future applications because it is too
generic, it is clear that existing applications may make use of it
for reasons of compatibility with older versions.

Aside from naming considerations, this proposal has a number of
advantages in our view. First, it is relatively easy to create a pure
Common LISP, portable environment by use of:

	(MAKE-PACKAGE 'xxx :USE 'COMMON-LISP), or
	(IN-PACKAGE 'xxx :USE 'COMMON-LISP)

Second, it is reasonably easy to remove extended definitions from the
USER environment:

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

Third, the default user environment (i.e. the USER package) is
consistent with the default environment provided by MAKE-PACKAGE and
IN-PACKAGE. Although this aspect may not be crucial in the future
package structure, it is likely to enhance the ease of use and
conceptual clarity of the package system, especially to new LISP
users. Notice that in this case writers of portable code need to
explicitly specify default values to MAKE-PACKAGE and IN-PACKAGE in
order to get a pure Common LISP enviroment. This is consistent with
the fact that portable code writers are likely to be required to
have a more thorough knowledge of the package system than new users
would. 

Special attention needs to be given to the problem of white page
objects whose CLtL definition has been extended by an implementation.
At the least, we plan to emphasize in our documentation those aspects
of CLtL specified objects that have been extended by the VAX LISP
implementation. In addition, we are also considering providing double
implementations for objects that have undergone significant
extensions in our implementation, such as FORMAT and MAKE-ARRAY.

A last remark is about a variable (or a SETF'able function) bound to
the package to be used as the default to MAKE-PACKAGE and IN-PACKAGE.
We believe that this variable would be meaningful only if all Common
LISP implementations agree not only on its syntax and semantics, but
also on its initial value. For the time being, in our opinion, this
variable is not required in order for people to write portable Common
LISP code, although we are again willing to consider other proposals
as well. Thanks,


				Ugo Buy
				
				ARPAnet:  BUY%BARTOK@HUDSON.DEC.COM

------