[Openmcl-devel] Package-local nicknames

Robert Goldman rpgoldman at sift.info
Wed Feb 6 07:39:00 PST 2013


On 2/6/13 Feb 6 -9:28 AM, Tim Bradshaw wrote:
> 
> On 6 Feb 2013, at 14:25, Josh Marchán wrote:
>> A while back, I started playing with the idea on CCL and added it to 3b's
>> package-local-nicknames library. It's certainly not complete and it's an
>> awful hack, but it's a nice proof-of-concept:
>>
>> https://github.com/sykopomp/package-local-nicknames
> 
> For what it's worth I think the right thing to add right now is not package-local-nicknames but a standard mechanism of hooking name->package lookup on which can be built anything you like.   The traditional way of doing this is to redefine FIND-PACKAGE, but that does not work for all implementations (including CCL).  If we could get everyone to agree that *any* name->package lookup checks (I am making this up as I go) *FIND-PACKAGE-HOOK* and if it is non-nil calls it with the name of the package, expecting two values: 
> 
> 	a package and T meaning use this
> 	nil and T meaning nothing found, and do not call the default function
> 	nil and nil meaning nothing found and call the default function.
> 
> *FIND-PACKAGE-HOOK* should be bound to NIL during the call, so the hook can call FIND-PACKAGE without fear (which it will very often want to do).
> 
> I have no idea what package *FIND-PACKAGE-HOOK* should be in.
> 
> Once something like that exists then you can build any user-level thing you like on it.

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*?

We need something that will use contextual information, and that can
merge settings from different contexts.

Note that the package-local-nicknames does meet these requirements,
because *PACKAGE* provides the context, different libraries can
configure the lookup behavior on a package-by-package basis, and
different libraries typically don't share packages, so they are safe
from interference.

Any extension proposal would have to be better than
package-local-nicknames, IMO, in order to be acceptable.

best,
r





More information about the Openmcl-devel mailing list