[Openmcl-devel] Package-local nicknames

[Hans Hübner]

I started writing up something that I intended to evolve into a CDR:
http://paste.lisp.org/display/133561

There were some valid concerns and when looking at the CCL code, I found
the code sufficiently complex to make implementing such a proposal harder
than I had hoped for.

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.

-Hans


On Wed, Feb 6, 2013 at 6:39 PM, Tim Bradshaw <tfb at tfeb.org> wrote:

> On 6 Feb 2013, at 15:39, Robert Goldman wrote:
>
> > I like the idea of a general mechanism, but I don't think this hook
> > variable will meet the ticket.
> >
> > What happens when there are two libraries that set *FIND-PACKAGE-HOOK*?
>
> Then they need to get together and either provide an extensible mechanism
> built on this (ie make the hook function do some kind of "method
> combination"), or at least detect that some other library has already
> hooked lookup: it's not very hard to imagine a library which checks for
> that, and if it is, calls the existing hook either before or after its own.
>  A library which did not at least *detect* an existing binding would be
> remiss.  Given that we can't possibly know if two libraries which might
> want to hook package lookup are in any way compatible, and that they often
> will not be, then specifying some (presumably complicated) mechanism by
> which they can cooperate seems inappropriate for an implementation.
>
> >
> > We need something that will use contextual information, and that can
> > merge settings from different contexts.
>
> My whole point was not to do that, because that is complicated, especially
> as we have no idea of what this contextual information actually *is*, but
> instead to provide a minimal mechanism, on which CL implementations can
> agree, and on which such a thing can be built: that's what this is.  Using
> it you can both easily provide package-local nicknames (as I have done), or
> do any number of other things that people might want.
>
> >
> > Any extension proposal would have to be better than
> > package-local-nicknames, IMO, in order to be acceptable.
>
> I think you are confused about levels: this is not competing with
> package-local nicknames, it is allowing package-local nicknames to be
> implemented portably.
>
> To respond to another message: unless implementation-hackers is it (do any
> of the CCL implementors read it?) I am not aware of another forum outside
> CLL, which I no longer read.
>
> --tim
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130206/8ab46043/attachment.htm>