Multiple dispatch (Re: Q: Python 2.0 preliminary features?)

[Tim Peters]

[Greg Ewing]
> Multiple dispatch is an attractive idea, but it makes me uneasy.
> One reason is that it's not clear what the rules should be.
>
> Suppose AA is a subclass of A, and BB is a subclass of B,
> and there are methods defined for the combinations
> foo(A, B), foo(AA, B) and foo(A, BB).
>
> Now, if you make a call with the combination foo(AA, BB),
> which method should get called?
>
> Arbitrary rules can of course be invented, but there is
> no single choice that is obviously "right" the way there
> is with single dispatch.

The first language I saw that took multimethods seriously was Cecil.  As is
often the case for pioneers, they answered the question in *the* obviously
right way, then waited a decade for everyone else to realize that subsequent
"improvements" weren't <wink>:  in Cecil, it's an error to call foo(AA, BB),
precisely because it's hopelessly ambiguous.

In the absence of static typing, this makes for a curious new class of
error:  adding a new multimethod can cause previously-working code to blow
up at runtime, if the new MM introduces new ambiguities (e.g., if only
foo(A,B) and foo(AA, B) were defined, foo(AA, BB) was called and resolved to
the latter, then you add a new foo(A, BB)).  You really, really, really want
to get told about that at compile-time.

There's much interesting reading (including rigorous definition of Cecil's
dispatching scheme) at:

http://www.cs.washington.edu/research/projects/cecil/www/Papers/papers.html

your-brain-won't-explode-but-your-compiler-might<wink>-ly y'rs  - tim