I haven’t blogged about this before, but that doesn’t mean I haven’t given some serious thought to it. It just needs more serious thought.

The problem is Multimethods. Perl 6’s operator system is all based around multimethods. And the current multimethod thinking around the entire programming community gives me the heeby geebies, as Perl 6’s junctions did before I tore them to shreds for the greater good :-). I think I need to do precisely the same thing I did there: fall back to programming’s mathematical basis.

Whenever a programming feature strays far from mathematics, things start getting inconsistent and difficult to work with. Non-mathematical features tend to have major scaling problems. I don’t know why, I just know that it’s true. When the operator system of a large language is based on something, it had better be scalable.

I argue that the current conception of multimethods are far beyond “far from mathematics”. They are a travesty in its name; they wave math in math’s own face like a baby wielding a daggar. I’ll tell you the beginnings of my argument (my whole argument will appear in the paper I write describing this). I’d be appreciative to be pointed to any prior research in the area, as I’ve come across none.

First think of a class as the set of all (possible) instances of the class. Any method in a class C is a map with domain C. Now think of what inheritance means. If a class D inherits from a class B, then all objects in D are also objects in B. So D is a subset of B.

Now consider an inheritance heirarchy where B ⊂ A, C ⊂ A, and D ⊂ B. Take a moment to picture this. In the current conception of multimethods, they say that D is *more derived* than B. I can understand that, since D ⊂ B. But they also say that D is *more derived* than C. This is the flaw. To make matters worse, most methodologies (like Class::Multimethods) say that D is *exactly twice as derived* as C (from A). This is preposterous! Look at the definitions carefully. Could D have fifty elements and C have one? Sure. Could even C ⊂ D? Sure it could. All that we know is that C is a subset of A, and that D is a subset of A. There could be (and are) hundreds of classes between A and C. Just because we don’t name them doesn’t mean they don’t exist.

Here’s where it gets completely awful. Okay, so D is twice as derived as C from A. So let’s define the distance d(A, D) to be 2 and the distance d(A, C) to be 1. This is a reasonable thing to do if you’re going to say that first silly statement. Now, to resolve which map *m* in the set M to use, we add up each distance from parameter to argument positionally. So given a map J: A × B → X (X is not important) and a particular pair of arguments in the sets (C, D) for example, the *distance* from the map to the tuple is d(A,C) + d(B,D) = 1 + 1 = 2. We do this for every candidate map, and whichever one has the lowest sum distance is the one we call.

Do you see my point? We’ve taken the set-theoretical concept of classes, grafted on this idea of “order of derivation”, summed these together in an arbitrary fashion (tuple inner product with operators (*d*, +)), and used this as the measure of applicability. We’ve strayed far, far away from mathematics, only to come back to it at the end with a bunch of irrational defintions, and we claim that the result is “mathematical”. Highly dubious.

That’s the beginning. I’ll start my blog entry on the beginnings of my solution now. Stay tuned.

Did you check my work on NOOP?