Package Odor

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

[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 
      typed langugage.

  (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 
      categories:
	(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
              defstruct descriptors].
      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 --