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

[Louis Madon]

Greg Ewing wrote:
> I'm a bit bothered by the idea that *adding* a new
> method could cause previously valid calls to become
> invalid. If I have only foo(A, B) and foo(AA, B)
> defined, then calling foo(AA, BB) is okay. But if
> I add a foo(A, BB), then all my existing foo(AA, BB)
> calls, anywhere in the program, suddenly become ambiguous.

This scenario is telling you something about your architecture: perhaps
you shouldn't be calling foo(AA, BB) or perhaps you should do some
refactoring of the class model or perhaps you need to add a specific
foo(AA, BB) method.  IMHO, this process helps to produce a better
architecture.

> 
> I worry that it will be difficult to reason about the
> behaviour of a program with MD

Without MD, programmers will invent adhoc workarounds to simulate it
(eg. explicit type tests or adding extra levels of indirection like in
the visitor pattern). Now lets say you've got to work on a 50kloc
program that was originally written by someone else, do you really think
that having such adhoc mechanisms sprinkled throughout the code makes
reasoning *easier*? I think the opposite is true; use of well defined
abstractions leads to easier to understand systems.

> because the information
> needed to determine which method a given call will
> invoke is spread out over many places, with no clear
> way of finding all of them. If I'm looking for the
> implementation of foo(A, B), will it be in the module
> defining A, or B? Or somewhere else entirely?
> What about foo(A, B, C, D, E)? It seems that I have
> a lot more possible places to look when I'm trying
> to find a piece of code.

I see the issue of finding where the various bits of code are as
separate to the notion of "reasoning about behaviour".  A decent code
browser should be able to automate this process for you.  In Harlequin
Dylan for example, the IDE lets you navigate through your code in a
variety of ways including looking up related methods. 

> I was thinking about it in the context of an interactive
> fiction authoring language. MD seems like an attractive idea
> there, because often a verb needs to be specialised in ways
> that depend equally much on all its arguments.

...
 
> Eventually I decided that what I really wanted was a set
> of pattern-matching clauses, like in functional languages.
> But for that to work it has to be clear what order the
> matches are tried in, which means that all the possible
> branches of an action really have to be listed together.
> That makes it difficult to have libraries of code which
> can be extended by the programmer.

Well your reasoning may well be sound here; MD is more expressive than
SD but that doesn't make it a solution for everything.  That's why I
find predicate dispatch so interesting, it generalises concepts like MD,
pattern matching, unification and others into a single elegant theory. 
Unfortunately, AFAIK, there is no language that implements it.

Louis.