Lambda the Ultimate

But still in "class-oriented" languages, the methods are attached to a given class, right?

Not necessarily. Since you mentioned Java, I'll focus there.

There are a couple of Java-like languages with multimethods and each chose a different path.

Nice separates multimethods from the class. When you call a Nice multimethod you can still put the first parameter before the message name, but it's not treated any differently otherwise.

In MultiJava you define both singlemethods and multimethods within a class. The result is that the first parameter of a multimethod is a bit more special than the others. You could even argue that MultiJava's dispatching isn't quite the same as full blown multimethods. It's a bit more like single dispatch + pattern matching. Once the single dispatch has routed to the right class, all the other different choices for the dispatch have to be defined in one place. It's just that the syntax looks multimethod-ish.

For more info on multi-methods in Java-like languages and on the JVM in general, check out this google groups link. Some of the links talk about the design trade offs of class-centric vs "open" multimethods.

I just found a link that calls the two strategies "symmetric" vs "asymmetric" multimethods. A symmetric multimethod is one where all the arguments are truly equal. With asymmetric multimethods some arguments are more special than others. In this case the discussion was about Groovy, another Java-like language with MultiJava-like asymmetric multimethods.

However, another link I found suggests that asymmetric multimethods treat the arguments in order: the first paramater is used to match first, then the second is used to match, and then the third, etc. In other words, for them asymmetric isn't the same as "encapsulated" or class-centered multimethods - asymmetric multimethods need not be encapsulated in a class. "Encapsulated" multimethods naturally introduce an asymmetry between the first argument and all the rest, but the rest of the arguments could be treated symmetrically or asymmetrically.

Assymetry may be used to resolve ambiguities--there are numerous ways of matching multimethods.

Consider the following pseudocode, with lots of stuff elided:

class B;
class D : public B;
class DD : public D;

void mm (B, B);
void mm (D, B);
void mm (B, D);
void mm (B, DD);

B b; D d1, d2; DD dd1, dd2;

What is the meaning of the following?

mm(d1,d2);

In a symmetric environment, the call is ambiguous. In an asymmetric environment favoring leftmost args, then the call to mm(D,B) would probably be chosen. But even then, there may be variances. What of

mm (dd1,dd2)??

Which is a better match for that? Some environments might use a "strict" leftmost regime, and select mm(D,B). Others might use a "best match" algorithm that looks for the best match regardless of order, and use ordering to break ties, and select mm(B,DD) on the grounds that one parameter is matched exactly. Which is better?

You tell me.

That link I pointed to on MultiJava was the first I had seen that suggested that asymmetry implied one particular pattern matching mechanism.

Most other things I'm looking at seem to agree with you that it's a more general term that indicates some form of asymmetry whether it's strictly left to right or not.

I found a paper on implementing multimethods in Smalltalk. They seem to use the terms "encapsulated" and "asymmetric" synonymously. But it strikes me that they're two different things. Encapsulated certainly implies one form of asymmetry but the converse isn't necessarily true. Another form of asymmetry (strict left to right, left to right tie breaking, or whatever) can certainly be practical in a language without class based encapsulation.

That link cites several other papers but I haven't followed up. Perhaps one could even answer the original question of where the term "multimethod" comes from.

Welcome to LtU! And incidentally, as long as you're here, I wonder if you'd be willing to answer another question...

I'm curious about the origin of the technical notion of "effectiveness" that you used in your OOPSLA talk. I know the word is also used in this sense in Smith's Origin of Objects, and I know that it occurs in your 1992 paper Towards a New Model of Abstraction in the Engineering of Software, where it appears that it may be a new coinage?

It seems like a very natural technical meaning for this word, and a very natural word for this notion, but still it must have an origin someplace, and I wonder if it's a widely used technical term that I'm just not familiar with.

And finally, highest compliments on the OOPSLA talk! It was by far the highlight of the conference.

I got the term effectiveness from Brian Smith who was using it even before 1992 when the Towards paper came out. I don't know exactly when/where/how he came to it.

PS Thanks about the talk.

Thanks!

Welcome to LtU!

For everybody else, here's the CommonLoops paper without the ACM gate. Unfortunately it's a document scan and hard to search. "Multi-method" does appear at several spots in the paper but so far I've found no citation and not much explanation indicating it might have already been a common term at that point.

I beg to differ. We used multimethods in Lisp machine system software years ago. We are using them now at ITA Software for our new airline reservation system. They work just as you'd expect them to. I have not seen any problems.

That's because you don't deal with potentially malicious code, dynamic code loading and other dynamic security issues, which is an increasingly important need for interesting software nowadays. You're working with a closed system, a trusted code base, with trusted modules and trusted administrators; that trusted computing base is HUGE, and not defensible. I'd like to see an attempt at writing defensible code using multimethods, and if auditing that code isn't the nightmare I expect it to be, then maybe I'll believe that they're sufficiently safe. Multimethods have all sorts of scoping issues that I suspect make auditing quite challenging.