Scott (long time no see):

This reply doesn't seem correct at all.  Interning an EQL specializer
does not directly have anything to do with methods (although it is
most often performed by the implementation when an EQL method is
defined) nor would  methods be remembered in the hash table or
whatever the implementation uses to intern them.

An EQL specializer must exist in order for METHOD-SPECIALIZERS to have
something to return, and as an argument to be passed to functions like
 SPECIALIZER-DIRECT-GENERIC-FUNCTIONS
 SPECIALIZER-DIRECT-METHODS
 EQL-SPECIALIZER-OBJECT

Specializers are also necessary if one wants to manipulate generic
functions and methods directly using the MOP instead of with the
DEFGENERIC and DEFMETHOD macros.  If for no other reason, specializers
exist because the MOP must be self-reflexive.

True, there is no way to remove an interned EQL specializer, which may
be an oversight in the MOP.  But there will be exactly one entry for
each unique specializer in the EQL hash table or whatever else is used
for their internment.  I suppose an implementation that features weak
hashtables could use one for EQL specializers, since if there were no
other references to one there would be no portable way to ask if it
was still there.

"Growing without bounds" is no different than what happens when a new
symbol is interned, or a new function or method is defined on an
interned symbol.  Rarely any problem in typical programming.

On Fri, Dec 26, 2014 at 7:38 AM, Scott McKay <swmckay@gmail.com> wrote:
> The specializers are probably interned for the sake of allowing
> better optimization of EQL dispatch. I don't think it'll grow without
> bounds; it probably gets big enough to hold all of the methods with
> EQL dispatch, and then grows no further.
>
> Honestly, I don't use EQL methods much myself, if they can be
> avoided by using SELECT.
>
> --S
>
>
> On Fri, Dec 26, 2014 at 10:33 AM, Kenneth Tilton <ken@tiltontec.com> wrote:
>>
>> Not sure where I see either "forever growing" or "memory leak". Come to
>> think of it, not sure what you mean by "mandatory". It is a spec of how the
>> MOP should work internally. Do you have some other way in mind for things to
>> work?
>>
>> I mean, it sounds like you might be talking about forever adding and
>> removing eql-specialized methods, but I'd rather not guess. Even if so,
>> nothing stops the implementation from GCing unused specializer metaobjects.
>>
>> -hk
>>
>>
>> On Fri, Dec 26, 2014 at 2:10 AM, Jean-Claude Beaudoin
>> <jean.claude.beaudoin@gmail.com> wrote:
>>>
>>> Hello CL Pros,
>>>
>>> Lately I have been improving the MOPishness of MKCL and that brought me
>>> in contact with the specification of intern-eql-specializer in AMOP.
>>>
>>> The EQ requirement on its returned value seem to me to dictate a
>>> hash-table implementation (PCL and its derivatives all seem to do just
>>> that).
>>>
>>> The problem I see with this is that it will be a "for ever growing"
>>> hash-table with not upper bound in sight. And the "purpose" of such a
>>> mandatory built-in memory leak also completely escapes me. Could any of you
>>> share some insight on this question, please?
>>>
>>> Thank you,
>>>
>>> JCB
>>>
>>>
>>> _______________________________________________
>>> pro mailing list
>>> pro@common-lisp.net
>>> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
>>>
>>
>>
>>
>> --
>> Kenneth Tilton
>> Fort Lauderdale, FL
>> http://tiltontec.com
>> "In a class by itself." -Macworld
>>
>>
>>
>> _______________________________________________
>> pro mailing list
>> pro@common-lisp.net
>> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
>>
>
>
> _______________________________________________
> pro mailing list
> pro@common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
>

_______________________________________________
pro mailing list
pro@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro