[Openmcl-devel] Package-local nicknames
csr21 at cantab.net
Thu Feb 7 02:33:32 CST 2013
Tim Bradshaw <tfb at tfeb.org> writes:
> On 6 Feb 2013, at 19:01, Hans Hübner wrote:
>> I think that some cross-platform mechanism for local nicknames is
>> needed, but I'm not sure whether the hook based package name
>> resolution proposal is really better than an extended defpackage now.
>> It would make sense to have something that implementors would
>> actually (be able to) adopt.
> Once again I'll say it: the advantage of a hook (or some similar
> substrate mechanism)
I think one of the lessons from years of CL might be that a hook
variable is too general for implementation of specific intercession
mechanisms: it is very convenient for individual users, but makes
interoperability between libraries a hard problem and makes compilation
from static inferences almost impossible. (Hooks operating at
compile-time may not suffer from the latter problem). So when talking
to implementors I think it's not right to talk about hooks and "similar
substrate mechanisms" in the same breath.
For what it's worth, I think that something along the following lines
can work: (find-package <thing>) should be specified to call
(find-package-using-package <thing> *package*); methods can be written
which specialize on the second argument of find-package-using-package,
and users are allowed to subclass the standard package class.
The standard package class is specified to implement an
implementation-defined superset of the standard functionality; packages
are specified not to be portably allowed to have their classes changed.
Then, "efficient" find-package on standard-classes, as Gary described,
can still be done guarded by a single boolean test on *package*, along
the lines of
(if (standard-package-p *package*)
(find-package-using-package "foo" *package*))
and users and library developers can use the existing CLOS mechanisms to
implement dispatch to their own desired functionality.
(I don't normally read this list; I will not read replies sent to it.)
More information about the Openmcl-devel