Operator overloading revisited

Brendan Eich brendan at mozilla.com
Tue Jun 30 09:56:31 PDT 2009


On Jun 28, 2009, at 7:05 AM, Christian Plesner Hansen wrote:

> I'd like to propose an alternative approach that avoids these
> problems.  You could call it "symmetric" operator overloading.  When
> executing the '+' operator in 'a + b' you do the following (ignoring
> inheritance for now):
>
> 1: Look up the property 'this+' in a, call the result 'oa'
> 2: If oa is not a list give an error, no '+' operator
> 3: Look up the property '+this' in b, call the result ob
> 4: If ob is not a list give an error, no '+' operator
> 5: Intersect the lists oa and ob, call the result r
> 6: If r is empty give an error, no '+' operator
> 7: If r has more than one element give an error, ambiguity
> 8: If r[0], call it f, is not a function give an error
> 9: Otherwise, evaluate f(a, b) and return the result.

This reinvents asymmetric multimethod dispatch without any inheritance  
or subtype specificity, i.e. with single-element class precedence  
lists and therefore no need to judge best-fit or most-specific method  
among the lists. You just pick the one that matches, and it's an error  
if zero or more than one match. Lots of references from the nineties  
to relevant work, e.g.,

http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html

under "Design: Symmetric vs. Encapsulated Multimethods", which leads  
to the [Boyland 1997, Castagna 1995, Bruce 1995] refs. The ES4 generic  
functions proposal has refs at the bottom too. It's necessary to put  
on your subclass/subtype-filtering glasses when reading, of course,  
but then the images resolves into very much what you propose.

Also, if you know Python and haven't seen this yet, have a look at:

http://www.artima.com/weblogs/viewpost.jsp?thread=101605

There are differences to debate between symmetric and asymmetric or  
encapsulated multimethods, and we can defer the CPL until (and it's  
not for sure) we have some user-extensible notion of subtyping, but I  
want to stress that the multimethod cat is out of the bag here. I like  
the gist of your proposal, it is a round-enough wheel. ;-)

Whether it should be extended to non-operator methods is something  
else we can debate, or defer. I claim there's nothing special about  
operators, and given other numeric types one might very well want  
atan2 multimethods.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090630/cdde1d37/attachment-0001.html>


More information about the es-discuss mailing list