3 ms·
Yup, overloading existing operators for new meanings is smelly. It’s better if the language allows creating new operators, so you’re not stepping on someone els
by evincarofautumn 9y ago
Yup, overloading existing operators for new meanings is smelly. It’s better if the language allows creating new operators, so you’re not stepping on someone else’s semantics. For example, Haskell has “</>” in the “filepath” package as an alias of “combine”. Custom operators can certainly be abused, but most packages that define operators only do so for good reason, and crucially they’re still searchable with Hoogle.
- Animats 9y agoYou can even set the precedence of your new operator in Haskell, and confuse everybody. Maybe beyond +, -, *, and /, you should have to use parentheses. Here's C's operator precedence.[1] All 15 levels. Think of the maintenance programmer who will have to fix this. [1] http://en.cppreference.com/w/c/language/operator_precedence http://en.cppreference.com/w/c/language/operator_precedence
- evincarofautumn 9y agoEh, I’ve gotten somewhat confusing type errors from mixing precedence levels in Haskell, but no bugs that I can recall. I’d like it if the levels were named instead of numbered, though—I have a hunch that the majority of operators fall into a family like “additive”, “multiplicative”, &c. People have experimented with relative precedence levels (and I believe Perl6 does this?) where you can say “this is lower-precedence than that” and you have to use parentheses to disambiguate expressions that mix operators unrelated by that partial order.