How should generic functions be exported from their home packages?
If a function like DESCRIBE is already in conventional use, then
it seems best NOT to attempt to export it from "RANDOM" package
even though this package may specialize DESCRIBE methods to its
own random classes. Of course, the "RANDOM" methods must remain
congruent with whatever interface has come into conventional use.
[I'm somewhat confused about how this works anyway. Does method
dispatching ignore the packages of function/method specifiers?]
Exporting the DESCRIBE interface from "RANDOM" would cause conflict
with the home package in implicit use (e.g., "LISP") where explicit
use of the "RANDOM" package is also requested.
In the event that a function like INVERT may await conventional
definition, its interface MUST BE exported from "RANDOM". In
this case, otherwise congruent interfaces defined in separate
packages seem obligated to generate SYMBOL-PACKAGE conflicts.
Some sort of "KEYWORD" package for generic function specifiers
might alleviate this interface registration problem. It appears
there is no conventional "home" package for generic functions.
Chris
--
Phone: (602) 994-6835 EMail: ····@sps.mot.com
From: Daniel A Haug
Subject: Re: Interface Export: Protection at the Boundary
Date:
Message-ID: <312@shrike.AUSTIN.LOCKHEED.COM>
In article <··················@buckwheat.mot.sps.com>, ····@buckwheat.mot.sps.com (Chris Hume) writes:
> How should generic functions be exported from their home packages?
>
> If a function like DESCRIBE is already in conventional use, then
> it seems best NOT to attempt to export it from "RANDOM" package
> even though this package may specialize DESCRIBE methods to its
> own random classes. Of course, the "RANDOM" methods must remain
> congruent with whatever interface has come into conventional use.
> [I'm somewhat confused about how this works anyway. Does method
> dispatching ignore the packages of function/method specifiers?]
I'm not sure I follow this. You export symbols, not functions. Once
you export the symbol DESCRIBE from "RANDOM", all users of "RANDOM"
inherit all aspects of that symbol, including its function definition
(e.g. the generic function with ALL of its associated methods), and
all of the other cells of the symbol. Defining methods uses the
method name (i.e. the symbol) to locate the generic function spec
to which the method is added. So, packages at the generic function
and method specification are most certainly important.
>
> Exporting the DESCRIBE interface from "RANDOM" would cause conflict
> with the home package in implicit use (e.g., "LISP") where explicit
> use of the "RANDOM" package is also requested.
Perhaps this is specific to the Symbolics, but I doubt it: if I create
package "FOO" that uses "COMMON-LISP" and "RANDOM", which each export
DESCRIBE, then if the symbol in RANDOM is the SAME symbol as the
one exported from CL (i.e. RANDOM inherits DESCRIBE from CL, then
exports it), there is no symbol conflict.
> In the event that a function like INVERT may await conventional
> definition, its interface MUST BE exported from "RANDOM". In
> this case, otherwise congruent interfaces defined in separate
> packages seem obligated to generate SYMBOL-PACKAGE conflicts.
Indeed, in our project, which has several systems and packages
that are heavily layered, we have systems whose entire existance
serves only to define the interface for later definition. These
systems contain only a package definition, and a set of DEFGENERICs.
As you stated, this is the only effective way of eliminating
symbol conflicts for higher level systems.
Just to clarify, we might have a system called LOW that defines
package LOW. In LOW, we define several DEFENERICs and export those
symbols from LOW. Then, higher level systems that add method
specs to those generic functions would then use the LOW package
in their packages. These higher level systems would have their
own packages (with LOW on the use list), but would also EXPORT
any methods from their packages for even higher-level system
use.
>
> Some sort of "KEYWORD" package for generic function specifiers
> might alleviate this interface registration problem. It appears
> there is no conventional "home" package for generic functions.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nor should there be. This would violate the premise for having
a package system in Lisp in the first place. Of course, there is
no reason you can't define functions with keyword names as well.
> Chris
> --
> Phone: (602) 994-6835 EMail: ····@sps.mot.com
> ----------------------------------------------------------------
dan haug
--
Internet: ····@austin.lockheed.com
UUCP: ut-emx!lad-shrike!aihaug