Revisiting Decimal (generic algorithms)

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


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.



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


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

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


-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090116/eda1368e/attachment.html>


More information about the Es-discuss mailing list