[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