SYSV-STANDARD question
Greg Pfeil
I am doing a bit of a survey of existing use cases for method combinations, and I came across your SYSV-STANDARD combination. I'm doing a write-up on how they're used, their potential, etc. so I'm trying to understand all the ones I come across.
One thing that confuses me in SYSV-STANDARD is the local function
(sort-by-specializers (methods)
(mapcar #'cdr (sort (specializers methods) #'equal :key #'car)))
which (to eliminate the need for context) could be written as:
(sort-by-specializers (methods)
(sort methods #'equal :key (lambda (m) (car (method-specializers m))
Using EQUAL as the sorting predicate doesn't seem very productive. My guess is that the methods that use this combination don't have much dependency on each other, so the fact that the wrong comparator got typed in hasn't actually affected anything. Even so, I'm curious as to the intent. PRIMARY (which is what gets passed to SORT-BY-SPECIALIZERS) should already be sorted :MOST-SPECIFIC-FIRST. I thought perhaps (SORT … #'EQUAL) was a poor man's randomizer, but then the "sorted" order is carefully maintained later on, so that doesn't seem to be the case.
Any light you can shed on the situation?
Thanks.
Evrim Ulu
Hi Greg,
Thanks for pointing out the equal case. I've pretty similar thoughts on
that one. #'equal does not have pretty much effect on comparing classes,
#'eq can do a similar work. I didn't yet understand why it bothered you
that much. Could you enlighten me?
On the other hand, the other one, i've double checked my
repos/core-server/t/method.lisp test file. I think the one i have
written was intended to fmap the lattice in a different way than yours.
Yours is a linear one, mine should have grace'd the first class supers
on the lattice yet i have no proof on doing that.
Sorry to bother you with my poor coding skills, it has been appr. 6
years that i've written that piece.
Regards,
--
Evrim Ulu <ev...@core.gen.tr>
Kor Information Technologies Ltd. - http://www.core.gen.tr
Greg Pfeil
Well, the thing here isn't #'eq vs #'equal, but that neither is a suitable predicate for SORT.
From the spec: “If the key consistently returns meaningful keys, and the predicate does reflect some total ordering criterion on those keys, then the elements of the sorted-sequence will be properly sorted according to that ordering.”
Equality does not reflect a total ordering, so your call to SORT does not sort anything. The predicate should be something like #'< (although that is not going to work on specializers). If you are trying to sort by the class precedence list, then that work is already done when your method combination is called, and you can eliminate the SORT. If you are trying to sort by something else, then I don't know what that might be.
> On the other hand, the other one, i've double checked my repos/core-server/t/method.lisp test file. I think the one i have written was intended to fmap the lattice in a different way than yours.
I'm not sure what you mean by yours and mine. The two versions of SORT-BY-SPECIALIZERS I quoted are equivalent. The latter was just transformed to eliminate the need to include the extra local functions. In the version in the source:
(labels ((specializer (method)
(car (sb-mop:method-specializers method)))
(specializers (methods)
(mapcar #'(lambda (m) (cons (specializer m) m)) methods))
(sort-by-specializers (methods)
(mapcar #'cdr (sort (specializers methods) #'equal :key #'car)))
...)
...)
is exactly equivalent to
(sort-by-specializers (methods)
(sort methods #'equal :key (lambda (m) (car (method-specializers m))
except that in the short version, the specializer is looked up more than once per method.
> Yours is a linear one, mine should have grace'd the first class supers on the lattice yet i have no proof on doing that.
I'm not sure what this sentence means.
> Sorry to bother you with my poor coding skills, it has been appr. 6 years that i've written that piece.
Not at all. I understand it can be hard to get your head back into something you haven't looked at in years. I am just trying to figure out as much as I can about interesting uses of method combinations. There are not that many around, and yours is one of them.
Evrim Ulu
> On 28 Feb 2012, at 16:47, Evrim Ulu wrote:
>
> Well, the thing here isn't #'eq vs #'equal, but that neither is a
> suitable predicate for SORT.
>
Ha! I am totaly ashamed. Of course you are right.
>
>> Yours is a linear one, mine should have grace'd the first class
>> supers on the lattice yet i have no proof on doing that.
>
> I'm not sure what this sentence means.
Ok, in regards of the current codebase, this has no significance, we
can gladly skip.
> Not at all. I understand it can be hard to get your head back into
> something you haven't looked at in years. I am just trying to figure
> out as much as I can about interesting uses of method combinations.
> There are not that many around, and yours is one of them.
Thanks for nice words.
As a conclusion, i'll try to remove all the necassary details soon. I'm
kinda busy right now. Yet thanks for pointing out. I hope this will be a
nice addition for your article.