[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Hi Gumby! long time no see. I'd heard that you were at MCC].
re: Now I think defpackage itself is not even close to the right thing; ...
Neither do I. At one time, I thought a defpackage was the answer to package
problems, but I've gotten "cold feet" about it after devling into it deeper.
The two main thorns I see are:
(1) It only works "as advertised" if there are *no* lisp primitives for
making changes to the package system [e.g., EXPORT, USE-PACKAGE, etc].
If you have these others, the DEFPACKAGE/SYSTEM is no surety at all;
in fact, it would be just one more headache to worry about when a
universally-recognized set of conventions-for-winning is established.
[consider the questions raised by Sandra Loosemore in her message of
Fri, 12 Feb 88 13:00:34 MST]. Ruling out primitives for the user to
make updates to packages at runtime seems to me to go very much against
the Lisp tradition; sounds more like the constraints of a statically
(2) Unlike all other Lisp facilities, this one has to address the issue
of how to redefine a global structure. For example, if you have a
database file, and along comes a new-kid-on-the-block who says "Here
is the contents for that database file", then how do you resolve
the current contents, which many clients have already used and "cached"?
Do you flush the current contents entirely? Do you try to "unify" the
current and redefining contents, signalling errors if there is an
unresolvable request? Currently, CL definers fall into three
(i) Those like DEFUN which only update some slot of a symbol; they
do not attempt to merge the actions of the old function found
in that cell with the new definition. Lisp is well-accustomed
to the dynamic update of symbol slots; and some implementations
give you warnings when you do redefine.
(ii) Those like MAKE-PACKAGE which signal an error on any attempt
to redefine the name-to-package mapping [a global database]
(iii) Those like DEFTYPE and DEFSTRUCT which simply displace the
former definitions [the global database involved here is
the implementation-dependent one for type descriptors and
The CLOS specification tries to describe a "unification" algorithm for
class redefinition [i.e., which old methods to throw out and which to
retain, etc]. But I think such a think for packages is overly
complicated and prone to unforseen consequences, especially since it
doesn't really solve the "package problem".
I don't have an idea right now of just how many constraints are necessary
to fix the "package problem", but there certainly is room for disucssion.
For example, I might not want to accept the restriction that Mike Beckerle
proposed -- no user use of USE-PACKAGE -- even though his notion of a
style guide and better compiler specification looked good. There must be
other reasonable alternatives that don't sacrifice the inheritable nature
of CL's packages.
-- JonL --
- Package odor
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>