[Python-ideas] Democratic multiple dispatch doomed to fail (probably)

Neil Toronto ntoronto at cs.byu.edu
Sat Dec 15 01:28:32 CET 2007

Arnaud Delobelle wrote:
> Neil Toronto ntoronto at cs.byu.edu:
>> While kicking around ideas for multiple dispatch, I came across one of
>> Perl's implementations, and it reminded me of something Larry Wall said
>> recently in his State of the Onion address about how types get together
>> and democratically select a function to dispatch to. I immediately
>> thought of Arrow's Theorem.
> Maybe I'm wrong, but I don't think this theorem applies in the case of
> mulitple dispatch.  The type of the argument sequence as a whole chooses
> the best specialisation, it's not the case that each argument expresses a
> preference.  The set of choices is the set S of signatures of
> specialisations of the function (which is partially ordered), and the
> 'commitee' is made of one entity only: the function call's signature s. 
> To choose the relevant specialisation, look at:
> { t \in S | s <= t and \forall u \in S (s < u <= t) \implies  u = t }
> If this set is a singleton { t } then the specialization with signature t
> is the best fit for s, otherwise there is no best fit.

Let's call this set T. In English, it's the set of t's (function 
signatures) whose types aren't more specific than s's - but only the 
most specific ones according to the partial general-to-specific 
ordering. Most multiple dispatch algorithms agree that T has the right 
function in it.

Some kind of conflict resolution seems necessary. The number of ways to 
have "no best fit" is exponential in the number of function arguments, 
so punting with a raised exception doesn't seem useful. It's in the 
conflict resolution - when the set isn't a singleton - that multiple 
dispatch algorithms are most different.

Conflict resolution puts us squarely into Arrow's wasteland. Whether 
it's formulated as a social choice function or not, I think it's 
equivalent to one.

In a social choice reformulation of multiple dispatch conflict 
resolution, T are the candidate outcomes. (This much is obvious.) The 
types are the agents: each prefers functions in which the type in its 
position in the signature is most specific. Again, it's a reformulation, 
but I believe it's equivalent.

The application implements a social choice function: it picks a winner 
function based on types' "preferences". Arrow's Theorem doesn't care 
exactly how it does this - whether it has types vote or sums distances 
from whatever - it just says that however it does this, the result can't 
always be "fair". And "fair" doesn't even mean one type can't have more 
say than another by, for example, narrowing the subset first based on 
its own preferences. It only means that things don't act 
counterintuitively in general, that there's *some* means to every 
outcome, and that one agent (type) doesn't control everything.

Maybe, as not-useful as it looks, punting with a raised exception is the 
only way out.


More information about the Python-ideas mailing list