<div dir="ltr">I started writing up something that I intended to evolve into a CDR:  <a href="http://paste.lisp.org/display/133561" target="_blank">http://paste.lisp.org/display/133561</a><div><br></div><div>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.</div>


<div><br></div><div>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.</div>

<div><br></div><div style>-Hans</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 6:39 PM, Tim Bradshaw <span dir="ltr"><<a href="mailto:tfb@tfeb.org" target="_blank">tfb@tfeb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 6 Feb 2013, at 15:39, Robert Goldman wrote:<br>
<br>
> I like the idea of a general mechanism, but I don't think this hook<br>
> variable will meet the ticket.<br>
><br>
> What happens when there are two libraries that set *FIND-PACKAGE-HOOK*?<br>
<br>
</div>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.<br>


<div class="im"><br>
><br>
> We need something that will use contextual information, and that can<br>
> merge settings from different contexts.<br>
<br>
</div>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.<br>


<div class="im"><br>
><br>
> Any extension proposal would have to be better than<br>
> package-local-nicknames, IMO, in order to be acceptable.<br>
<br>
</div>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.<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
--tim<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
</div></div></blockquote></div><br></div>