[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 7 Jul 88 16:12 EDT
References: IN-PACKAGE (p183)
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Eliminate the ability of IN-PACKAGE to create a package on demand.
Require IN-PACKAGE to signal an error if the package does not exist.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
Clarify that DEFPACKAGE is the preferred way to declare a package,
and MAKE-PACKAGE is the preferred way to construct a package at runtime.
Eliminate the compile-time processing requirement for all package-related
functions except IN-PACKAGE and DEFPACKAGE.
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;signals an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
This would greatly improve error checking and modularity, with only minimal
loss of functionality. Any call to IN-PACKAGE which really needed to
demand-create a package could be rewritten as a DEFPACKAGE followed by an
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In many cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Pitman supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
As written, this proposal is necessarily contingent on DEFPACKAGE:ADDITION.
Note, however, that the attempt by this proposal to reduce the set
of arguments allowed to IN-PACKAGE is not inconsistent with the attempt by
DEFPACKAGE:ADDITION to increase the set of arguments. That proposal,
which is a compatible addition, presupposes that IN-PACKAGE is still
usable both for selection and creation, so it correctly attempts to
generalize the arguments it requires. This proposal, which is an
incompatible change, uses DEFPACKAGE as a foothold to change the model
of how IN-PACKAGE is used -- only once that new model is in place does
it make sense to consider eliminating arguments to IN-PACKAGE.