3 ms·

I agree with some the things he writes, but others seem blatant absurdities: > "the + operator is still both numeric addition and string concatenation. That is

I agree with some the things he writes, but others seem blatant absurdities: > "the + operator is still both numeric addition and string concatenation. That is frequently listed as one of the bad parts of JavaScript. Why no provide separate operators for the two?" The problem isn't operator overloading: the problem is implicit type coercion. Having to use 2 separate operators/functions for separate types when writing code, is useful only if types are actually checked at compile time, and the compiler can do inference on them (see the + and +. operators in F#) If you have a dinamically typed language, you can have sane semantics if you make it so that type conversions are explicit (e.g. Python, Ruby...) See also: http://james-iry.blogspot.it/2009/03/operator-overloading-ad-absurdum.html http://james-iry.blogspot.it/2009/03/operator-overloading-ad...

Dylan16807 13y ago
The problem is the combination of the two. You can have operator overloading if conversion is explicit. You can have a converting operator if the action is explicit. But you can't have loose overloading and automatic conversion at the same time without silly defects. Edit: And you didn't just disagree but call it a 'blatant absurdity' to blame the half of the problem that you happen to like better? Jeez.
- berdario 13y ago
  I agree, "blatant absurdity" is quite a strong wording. I should've wrote "quite dubious" or the like. In my defense, I didn't even think of having a language with type coercion and 0 operator overloading (even on builtin types). I never saw such a language, and I'm skeptical that it could work. But it's an interesting take on the problem. I cannot say why I think that the no-coercion+overloading is the better solution... maybe that's because operators are dyadic, and thus type coercion can be executed on both sides of the operator, and multiple times. While function application is (can be?) sort of monadic (in the APL sense) since coercion/overloading for an argument doesn't depend on the type of the other arguments supplied to the function (But while writing this, I'm not so sure anymore... at the very least, it could depend on the order in which arguments are evaluated...)
  - Dylan16807 13y ago
    What I think of here is Lua, where builtin types have no overloading and there is a single type of coercion, between numbers and strings. This coercion is only triggered by arithmetic operators and concatenation. Unambiguous and pretty harmless. (Technically objects can overload binary operators (with no coercion) but it's not very common)

Dylan16807 13y ago

The problem is the combination of the two. You can have operator overloading if conversion is explicit. You can have a converting operator if the action is explicit. But you can't have loose overloading and automatic conversion at the same time without silly defects. Edit: And you didn't just disagree but call it a 'blatant absurdity' to blame the half of the problem that you happen to like better? Jeez.

berdario 13y ago
I agree, "blatant absurdity" is quite a strong wording. I should've wrote "quite dubious" or the like. In my defense, I didn't even think of having a language with type coercion and 0 operator overloading (even on builtin types). I never saw such a language, and I'm skeptical that it could work. But it's an interesting take on the problem. I cannot say why I think that the no-coercion+overloading is the better solution... maybe that's because operators are dyadic, and thus type coercion can be executed on both sides of the operator, and multiple times. While function application is (can be?) sort of monadic (in the APL sense) since coercion/overloading for an argument doesn't depend on the type of the other arguments supplied to the function (But while writing this, I'm not so sure anymore... at the very least, it could depend on the order in which arguments are evaluated...)
- Dylan16807 13y ago
  What I think of here is Lua, where builtin types have no overloading and there is a single type of coercion, between numbers and strings. This coercion is only triggered by arithmetic operators and concatenation. Unambiguous and pretty harmless. (Technically objects can overload binary operators (with no coercion) but it's not very common)