4 ms·

Perhaps operators could only be overloaded, without any defined by the language itself. Then projects could define useful operators for their specific case to m

Perhaps operators could only be overloaded, without any defined by the language itself. Then projects could define useful operators for their specific case to make things more terse/infix/etc. while still requiring awareness of their implementation.

knome 3y ago
No. Haskell made me decide that operators should not be definable by users. It is truly a miserable affair to read terse point free code riddled with operators from a half dozen libraries ( or one overly clever library ). Cleverness is a register that is easy to overflow, and too many don't have to good taste to avoid doing so. Give me names every time.
- hollerith 3y ago
  Do you consider them as bad as user-definable Lisp or Scheme macros?
- j16sdiz 3y ago
  It depends on what you tries to do. Doing linear algebra without any operator overloading is just unreadable
  - layer8 3y ago
    I think GP meant users should not be able to define new operators (as is possible and fairly common in Haskell), but may still be allowed to overload the existing operators.
- wwalexander 3y ago
  That’s a good point. I suppose I was imagining something like internal-only operators that could be defined within the scope of a single module but not exported; though I suppose with any sufficiently large module with enough orthogonal pieces you’d still run into arcane and overly-terse operators.
golergka 3y ago
And each library will end up with its own semantics.
lmm 3y ago
Don't make "operators" a special case - make them just functions following the normal rules. Scala gets close to this (though sadly it still has some operator precedence rules). To define a function called "plus", you do "def plus" (or "fun plus" or whatever your syntax is). To define a function called "+" you do "def +". It's so much nicer and more consistent. Yes, some library authors abuse it to write functions or classes with dumb names, but you can write dumb names with letters as well.

knome 3y ago

No. Haskell made me decide that operators should not be definable by users. It is truly a miserable affair to read terse point free code riddled with operators from a half dozen libraries ( or one overly clever library ). Cleverness is a register that is easy to overflow, and too many don't have to good taste to avoid doing so. Give me names every time.

hollerith 3y ago
Do you consider them as bad as user-definable Lisp or Scheme macros?
j16sdiz 3y ago
It depends on what you tries to do. Doing linear algebra without any operator overloading is just unreadable
- layer8 3y ago
  I think GP meant users should not be able to define new operators (as is possible and fairly common in Haskell), but may still be allowed to overload the existing operators.
wwalexander 3y ago
That’s a good point. I suppose I was imagining something like internal-only operators that could be defined within the scope of a single module but not exported; though I suppose with any sufficiently large module with enough orthogonal pieces you’d still run into arcane and overly-terse operators.

golergka 3y ago

And each library will end up with its own semantics.

lmm 3y ago

Don't make "operators" a special case - make them just functions following the normal rules. Scala gets close to this (though sadly it still has some operator precedence rules). To define a function called "plus", you do "def plus" (or "fun plus" or whatever your syntax is). To define a function called "+" you do "def +". It's so much nicer and more consistent. Yes, some library authors abuse it to write functions or classes with dumb names, but you can write dumb names with letters as well.