Revisiting Decimal (generic algorithms)

Brendan Eich brendan at mozilla.com
Fri Jan 30 18:28:02 PST 2009


On Jan 16, 2009, at 9:05 PM, Mark S. Miller wrote:

> On Fri, Jan 16, 2009 at 5:34 PM, Brendan Eich <brendan at mozilla.com>  
> wrote:
> Have you looked at multimethods in Cecil?
>
> http://www.cs.washington.edu/research/projects/cecil/pubs/cecil-oo-mm.html
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.8502
>
> On your recommendation, I have. I really wanted to like it. I really  
> tried to like it. In the end I was repelled in horror at its  
> complexity.

You and David-Sarah should discuss your differenct reactions -- I'd  
genuinely appreciate the insights.


> Good discussion, let's keep it going.
>
> Indeed. After I made a simple proposal <https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html 
> >,

BTW, as I said to you at the TC39 meeting, I think the language is  
better off with what you propose in the Harmony timeframe than with  
nothing in the way of extensible operator support. Also, as Waldemar's  
notes reflect, after discussion we concluded that this is insufficient  
for decimal.


> Michael Daumling pointed out that Adobe had made a similar proposal  
> that had been rejected:
>
> On Fri, Jan 9, 2009 at 7:56 AM, Michael Daumling  
> <mdaeumli at adobe.com> wrote:
> The discussion about operator overloading quickly went away from the  
> JavaScript'ish approach that ExtendScript and your proposal used  
> towards generic functions. At some time, the discussion stranded in  
> areas too exotic for me. There is a rationale here: http://wiki.ecmascript.org/doku.php?id=discussion:operators
>
> The objections listed there are
>
> I think this feature is too weak to be included. Here are some  
> reasons why I think that:
>
> Uncontrollable subtleties in dispatch: Adding eg a == operator to  
> one class and then comparing an instance x of that class to a value  
> y of another type means that the result can easily differ depending  
> on whether the programmer writes x == y or y == x. (If y has an  
> operator == too then its operator will be preferred in the latter  
> case.) The most the author of the == operator can do about this is  
> to add types to the operator's signature so that strict mode catches  
> the bug or the program fails predictably at run-time.
> I'd argue that this is a feature, not a bug. Whether an operator is  
> commutative depends on the meaning of that operator on that data  
> type. "x * y" should mean the same as "y * x" if they are scalar  
> numbers but not if they are matrices.

Yes, but for many commutative operators there's no benefit and only  
cost to double-dispatch.


> No inheritance: in almost all cases we would wish that if instances  
> of A and B are comparable with a certain semantics then instances of  
> their respective subclasses C and D are too.
> That objection doesn't apply to my proposal. (I'm not sure it does  
> to Adobe's either.)

Depends on how you define "subclasses", but let's say this does not  
apply for prototype-based delegation. Ok -- fair enough.


> No compositionality: As the operators are tied to classes, a program  
> that wishes to use two separately authored classes A and B cannot  
> define their relations in terms of operators, the classes must be  
> altered because they do not know about each other.
> Again, I'd argue that this is a feature, not a bug. Likewise, if I  
> see the expression "x.foo(y)" and the meaning of the foo operation  
> does not treat its operands opaquely, if neither x nor y know about  
> each other's interface, then I'd expect the operation to fail. If  
> some party outside of x and y could define a generic foo that could  
> make this operation succeed anyway, I'd consider that a bug.

That's what I knew you'd say, but Chambers made the case well enough:

The generalization of receiver-based dispatch to multiple dispatch  
provides a number of advantages. For example, multimethods support  
safe covariant overriding in the face of subtype polymorphism,  
providing a natural solution to the binary method problem [Bruce et  
al. 1995; Castagna 1995]. More generally, multimethods are useful  
whenever multiple class hierarchies must cooperate to implement a  
method’s functionality. For example, the code for handling an event in  
an event-based system depends on both which event occurs and which  
component is handling the event.

MultiJava: Design Rationale, Compiler Implementation, and Applications
Curtis Clifton, Todd Millstein, Gary T. Leavens, and Craig Chambers

http://www.cs.washington.edu/research/projects/cecil/pubs/mj-toplas.html

Over and over, in Mozilla code and especially on the web, we've seen  
"code mashups" where one does not always have the money, or even the  
ability, to monkey-patch class A or class B to understand each other.  
Wrapping can be done to make a class C with operators, at some cost.  
Why this is always a feature and never a bug is not clear, and  
Chambers, et al. have researched a fix to it, viewing it as a bug to  
motivate their research.

> Including operators as currently proposed would probably give us a  
> headache if we wish to introduce a more powerful feature (probably  
> based on some sort of ad-hoc overloading) in the future.
>
> Functional folks often refer to oo polymorphism (or "late binding")  
> as "ad-hoc polymorphism", to distinguish it from their parametric  
> polymorphism. If this is what is meant, then my proposal and Adobe's  
> both provide ad-hoc polymorphism. If, as I suspect, something else  
> is meant, I await hearing what it might be.

According to http://en.wikipedia.org/wiki/Polymorphism_(computer_science) 
  (hey, it's referenced):

There are two fundamentally different kinds of polymorphism,  
originally informally described by Christopher Strachey in 1967. If  
the range of actual types that can be used is finite and the  
combinations must be specified individually prior to use, it is called  
Ad-hoc polymorphism. If all code is written without mention of any  
specific type and thus can be used transparently with any number of  
new types, it is called parametric polymorphism. John C. Reynolds (and  
later Jean-Yves Girard) formally developed this notion of polymorphism  
as an extension to the lambda calculus (called the polymorphic lambda  
calculus, or System F).

So multimethods use parametric polymorphism.

Lars's point about future-proofing, when he wrote "ad-hoc  
overloading", seems to me to be about adding extensible dyadic  
operators via double-dispatch now, then adding multiple dispatch in  
some form later and being prevented by compatibility considerations  
from changing operators. Best to ask him directly, though -- I'll do  
that.

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


More information about the Es-discuss mailing list