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
<code> <code>
[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: ····@sps.mot.com
In article <··················@buckwheat.sps.mot.com> ····@buckwheat.sps.mot.com (Chris Hume) writes:
>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).
DEFMETHOD, like just about everything else in Common Lisp, uses
whatever symbol it is given.
> 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.
I don't understand why generic functions adds complexity to the
package confusion. It's a well known problem of Common Lisp that the
package system is confusing (unfortunately, it's the best the
designers were able to come up with, and it's less complex than the
Zetalisp package system that on which it was based).
>The handy self-referential acronym documented in CLtL:
>
> "Put IN Seven EXtremely Random USEr Interface COmmands"
It's a mnemonic, not an acronym.
>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).
Yes, the mnemonic assumes that you're only exporting symbols
introduced in the package. Some discussion within X3J13 resulted in a
suggested new mnemonic: I REmember Six USEr Interface EXpressions.
This differs from your proposed order only in the interchanging of
REQUIRE and SHADOW (their relative order doesn't really matter), and
the elimination of PROVIDE (it generally belongs AFTER the code)
(since then, PROVIDE and REQUIRE have been removed from the language).
More significantly, though, X3J13 has added DEFPACKAGE to the
language. This is a single form that can generally be used to set up
a package, and it is required to do everything in the right order
(shadow, use, import/intern, export).
>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"?
Ignoring the fact that modules have been removed from the language
standard, the rationale for distinguishing their dependencies is that
their boundaries may not be the same. There might be several modules
in a single package. In this case, you'd probably put the package
definition in its own module, and have them all REQUIRE the
package-definition module.
There's not much work that I know of on the standardization of
systems. However, we've done quite a bit of work to improve the
portability of code that manipulates pathnames, and we've added
logical pathnames; these facilities are needed in order to write
portable code that implements systems.
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar