« Return to Thread: Operator overloading revisited

Re: Operator overloading revisited

by Brendan Eich-3 :: Rate this Message:

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

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: Operator overloading revisited