[Openmcl-devel] Package-local nicknames

Tim Bradshaw tfb at tfeb.org
Wed Feb 6 09:39:15 PST 2013


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


More information about the Openmcl-devel mailing list