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?
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
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
> 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
> - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss