Path: utzoo!utgpu!attcan!uunet!cs.utexas.edu!oakhill!dover!hume
From: hume@buckwheat.sps.mot.com (Chris Hume)
Newsgroups: comp.lang.lisp
Subject: Managing Package Dependencies
Message-ID: 
Date: 28 Sep 89 19:28:35 GMT
Sender: news@dover.sps.mot.com
Distribution: comp
Lines: 48

Thanks Dan, for your careful explanation.  The idea of a [kernel] package
in which a particular design organization's interfaces can find a common
"home" actually bears some similarity to my idea of having a "standard"
(or perhaps better, a "default") package for (generic interface) symbols.

Package conflicts will still arise, where products from independent design
organizations are "used together", the resolution of which might be expedited
by some level of convention for "kernel" package organization.

My package ignorance confusion arose because it had not occurred to me
that DEFMETHOD in a private package would use a symbol from some other
package (in implicit use).  This should have been obvious, but it may
suggest that Users will have some difficulty maintaining consistent
"package dependency" across modules that specify either interfaces
(via DEFGENERIC), their method, and their application.

The handy self-referential acronym documented in CLtL:

    "Put IN Seven EXtremely Random USEr Interface COmmands"

may introduce EXPORT prematurely.  To handle the case we have been discussing
(exporting a symbol one might incidentally inherit from another package)
it seems natural to move EXPORT below USE-PACKAGE (and probably also IMPORT).

        CLtL Recommendation     Alternative Order
        -------------------     -----------------
             PROVIDE                PROVIDE
             IN-PACKAGE             IN-PACKAGE
             SHADOW                 SHADOW
             EXPORT
	     REQUIRE		    REQUIRE
             USE-PACKAGE            USE-PACKAGE
             IMPORT                 IMPORT
                                    EXPORT
                              

[Either ordering may be modulated by introduction of "File Attributes".]

There are no doubt considerations (other than lack of a handy self-
referential acronym) that this alternative overlooks.  As a separate
topic I would like to understand the rationale behind distinguishing
module dependency from package dependency.  Can anyone characterize
the current state of standardization for the concept (and support)
of "systems"?

Chris
--
Phone: (602) 994-6835		EMail: hume@sps.mot.com