[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: IN-PACKAGE-FUNCTIONALITY (Version 3)
- To: firstname.lastname@example.org
- Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 3)
- From: masinter.pa@Xerox.COM
- Date: 8 Dec 88 15:24 PST
- Cc: masinter.pa@Xerox.COM
- Line-fold: no
References: IN-PACKAGE (p183)
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
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.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
#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 could allow improved 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:
As written, no change to implementations is required, but many
will want to make IN-PACKAGE signal an error.
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 some 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.
The cleanup committee supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some members support it only if DEFPACKAGE passes; others would like
to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
However, there might be some compilation problems if IN-PACKAGE
changes and MAKE-PACKAGE signals an error if the package exists.
The issue of compile-time processing of package related functions is
complex, and full of a number of compatibility issues. Should we remove
the requirement of special compile-time handling of IN-PACKAGE?
Should we disallow mid-file switching of *PACKAGE* or package
use lists? These issues are not addressed here.