Revisiting Decimal (generic algorithms)

Mark S. Miller erights at
Fri Jan 16 21:05:35 PST 2009

On Fri, Jan 16, 2009 at 5:34 PM, Brendan Eich <brendan at> wrote:

> Have you looked at multimethods in Cecil?

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.

> Good discussion, let's keep it going.

Indeed. After I made a simple proposal <>,
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> 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:
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.

>    -
>    - 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.)

>    -
>    - 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 "" 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.

>    -
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list