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

[Greg Ewing]

Louis Madon wrote:
> 
> Neither, you should get a "message ambiguous" error

That's a reasonable answer. Although you still need some
set of rules for defining when a call is ambiguous or
not. I think I can sort of see what rule you're using
here, but it's not easy to state concisely.

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.

I worry that it will be difficult to reason about the
behaviour of a program with MD, 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.

> But if the domain you need to model isn't naturally hierarchical you'll
> end up with redundancy in your class model

I know MI can be very handy, but it needs taming before
use. I know what needs to be done to MI to tame it, but
I haven't yet figured out how to similarly tame MD.
If I ever do, I may be more enthusiastic about it.

> Can you elaborate? I mean about MD + MI (Its ok, I'll keep a safe
> distance from you so feel free to self destruct while considering
> this

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. 

For that application, it's not really acceptable to crash if the
user happens to do something the author didn't anticipate,
so I wanted to come up with a complete set of rules to
cover all possibilities. But it got far too complicated
to be useful in practice.

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.

So I still haven't designed my killer IF language yet.
Maybe one day...

Greg