[Openmcl-devel] Package-local nicknames

[Christophe Rhodes]

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*)
      (constant-time-package-lookup "foo")
      (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.)

Christophe