<div dir="ltr">Why is there no way to remove an interned EQL specializer meta-object? They get defined in the context of a method definition, so one just needs to do some good old-fashioned engineering: method-specializer reference tracking leveraged at method removal time to know when to toss the hash table entry. <div><br></div><div>I am more interested in why this is perceived as a problem, but if the OP is doing some dynamic metaprogramming I can imagine a use case.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 11:58 AM, Steve Haflich <span dir="ltr"><<a href="mailto:shaflich@gmail.com" target="_blank">shaflich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scott (long time no see):<br>
<br>
This reply doesn't seem correct at all.  Interning an EQL specializer<br>
does not directly have anything to do with methods (although it is<br>
most often performed by the implementation when an EQL method is<br>
defined) nor would  methods be remembered in the hash table or<br>
whatever the implementation uses to intern them.<br>
<br>
An EQL specializer must exist in order for METHOD-SPECIALIZERS to have<br>
something to return, and as an argument to be passed to functions like<br>
 SPECIALIZER-DIRECT-GENERIC-FUNCTIONS<br>
 SPECIALIZER-DIRECT-METHODS<br>
 EQL-SPECIALIZER-OBJECT<br>
<br>
Specializers are also necessary if one wants to manipulate generic<br>
functions and methods directly using the MOP instead of with the<br>
DEFGENERIC and DEFMETHOD macros.  If for no other reason, specializers<br>
exist because the MOP must be self-reflexive.<br>
<br>
True, there is no way to remove an interned EQL specializer, which may<br>
be an oversight in the MOP.  But there will be exactly one entry for<br>
each unique specializer in the EQL hash table or whatever else is used<br>
for their internment.  I suppose an implementation that features weak<br>
hashtables could use one for EQL specializers, since if there were no<br>
other references to one there would be no portable way to ask if it<br>
was still there.<br>
<br>
"Growing without bounds" is no different than what happens when a new<br>
symbol is interned, or a new function or method is defined on an<br>
interned symbol.  Rarely any problem in typical programming.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Dec 26, 2014 at 7:38 AM, Scott McKay <<a href="mailto:swmckay@gmail.com">swmckay@gmail.com</a>> wrote:<br>
> The specializers are probably interned for the sake of allowing<br>
> better optimization of EQL dispatch. I don't think it'll grow without<br>
> bounds; it probably gets big enough to hold all of the methods with<br>
> EQL dispatch, and then grows no further.<br>
><br>
> Honestly, I don't use EQL methods much myself, if they can be<br>
> avoided by using SELECT.<br>
><br>
> --S<br>
><br>
><br>
> On Fri, Dec 26, 2014 at 10:33 AM, Kenneth Tilton <<a href="mailto:ken@tiltontec.com">ken@tiltontec.com</a>> wrote:<br>
>><br>
>> Not sure where I see either "forever growing" or "memory leak". Come to<br>
>> think of it, not sure what you mean by "mandatory". It is a spec of how the<br>
>> MOP should work internally. Do you have some other way in mind for things to<br>
>> work?<br>
>><br>
>> I mean, it sounds like you might be talking about forever adding and<br>
>> removing eql-specialized methods, but I'd rather not guess. Even if so,<br>
>> nothing stops the implementation from GCing unused specializer metaobjects.<br>
>><br>
>> -hk<br>
>><br>
>><br>
>> On Fri, Dec 26, 2014 at 2:10 AM, Jean-Claude Beaudoin<br>
>> <<a href="mailto:jean.claude.beaudoin@gmail.com">jean.claude.beaudoin@gmail.com</a>> wrote:<br>
>>><br>
>>> Hello CL Pros,<br>
>>><br>
>>> Lately I have been improving the MOPishness of MKCL and that brought me<br>
>>> in contact with the specification of intern-eql-specializer in AMOP.<br>
>>><br>
>>> The EQ requirement on its returned value seem to me to dictate a<br>
>>> hash-table implementation (PCL and its derivatives all seem to do just<br>
>>> that).<br>
>>><br>
>>> The problem I see with this is that it will be a "for ever growing"<br>
>>> hash-table with not upper bound in sight. And the "purpose" of such a<br>
>>> mandatory built-in memory leak also completely escapes me. Could any of you<br>
>>> share some insight on this question, please?<br>
>>><br>
>>> Thank you,<br>
>>><br>
>>> JCB<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> pro mailing list<br>
>>> <a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
>>> <a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Kenneth Tilton<br>
>> Fort Lauderdale, FL<br>
>> <a href="http://tiltontec.com" target="_blank">http://tiltontec.com</a><br>
>> "In a class by itself." -Macworld<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> pro mailing list<br>
>> <a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
>> <a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> pro mailing list<br>
> <a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
> <a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
><br>
<br>
_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
<a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Kenneth Tilton<div>Fort Lauderdale, FL</div><div><a href="http://tiltontec.com" target="_blank">http://tiltontec.com</a><br></div><div>"In a class by itself." <i>-Macworld</i></div><div><br></div><div><br></div></div></div>
</div>