> I don't think that would work. It is not enough to order by the "top
> class". I think this problem is an example where a binary predicate
> is better fit as it naturally expresses the programmers idea while a
> unary weight would have to be computed somehow: assuming that a unary
You are probably right. At least it is much harder to come up with a
> weight always exists, I can imagine that it could be computed from the
> binary predicate taking into account the size of the set being sorted;
I would not think to compute a single numeric value, but a list of
values in the order of sort priority (the same order a binary function
would perform a sequence of checks). But still it is not easy, and I
must confess that I did not understand the exact requirements for the
ordering of class lists in your multi-method example well enough.
> I still think it would be better if the 'sort' function had a second
> optional argument to specify a binary predicate and the decision which
Right. It would be a useful extension anyway.
> developer. And the C code would not be that much more complicated or
> inefficient for the existing approach/code.
True. Efficiency is not a problem here. And the original semantics, with
the fast built-in comparisons, would be still available anyway.
However, 'sort' will be a bit more complicated than in your proposal:
The current implementation does not need to save its arguments, because
it can be sure that the garbage collector will not run during its
execution. If you evaluate a user-supplied function, however, you cannot
assume this. Thus, the argument list, as well as the result lists and
perhaps also the intermediate pointers, have to be pushed into stack
frames, and popped upon return. This is the case for 'out', most
probably for 'in', and perhaps also 'p', 'last' and 'tail' (to
know for sure, I would have to analyze the algorithm again, as I forgot
the details after almost 10 years ;-)