Origin of the term Multimethod

Does anyone here know the origin of the term "multimethod"?

I would guess that the term "multiple dispatch" sprang from common OO dispatch table (or vtable) implementation of single dispatch, and carries the OO bias of a "this" argument (no point saying "multiple" without a "single" as an assumed baseline). Does the "multi-" in "multimethod" stem from similar thinking or from a more functional orientation (perhaps the "multi" meant to suggest the several function implementations that may be invoked by a given function call)?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Multiple dispatch

I'm pretty sure it's a shortening of "multiple dispatch method." But "multimethod" isn't universal terminology. CLOS uses the phrase "generic function" to mean the interface definition and "generic method" to mean an individual method that is "attached" to a generic function. If I recall, Dylan uses similar terminology.

Note that "single dispatch" may or may not have anything to do with a vtable. A vtable is a popular implementation technique but there are certainly others (e.g. dictionaries). Single dispatch means that the function to be evaluated is chosen or "dispatched" at runtime based on a single parameter. In many (most?) single dispatch languages that special parameter, the "target object," is put before the message name to indicate it's specialness.

With multimethods all the arguments are equally special.

Multiple dispatch

With multimethods all the arguments are equally special.

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

I have read a discussion on the Scala mailing list on the opportunity to implement multiple dispatch in Scala. From that discussion, I had the impression that this would have profound impacts on the language usage.

I can indeed see how multiple dispatch can benefit some situations (and I just recently had one of those in Java, so this is not a pure academical interest) but I still don't see how the "equal rights" for arguments would impact system design.

What's the experience of people using it on a daily basis?



Exactly like pattern matching but totally different

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.

symmetric vs asymmetric mutlimethods

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.

Not necessarily

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?


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.

Assymetric vs encapsulated

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.

Origin of term multi-method

The term appears in the first CommonLoops paper, so its from at least 'back then'. My memory is far from perfect, but I think Larry Masinter came up with the term at the same time as he added multi-methods to the original Interlisp implementation of what became CommonLoops.


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.

Origin of term 'effectiveness'

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.



Obligatory link

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.

Multimethods are compelling,

Multimethods are compelling, but they need a lot more study before they can be used safely and effectively. Even more compelling is predicate dispatching. Unfortuantely, multiple dispatch has consequences for encapsulation and security, and I haven't seen these issues being addressed. The Nice language tackles some of the safety concerns, but I don't think its treatment is adequate in the presence of dynamic loading, which raises a number of security concerns.

Use of multimethods

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

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.