4 ms·

Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell: https://haskell-lang.org/tutorial/operators ht

by wtracy 8y ago

Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell: https://haskell-lang.org/tutorial/operators https://haskell-lang.org/tutorial/operators

jhayward 8y ago
Those are mostly library functions, not part of the language. It doesn't seem any more reasonable to use them to declare Haskell a complex language than it would to have the existence of, say, a linear algebra library providing mathematical operators for Forth mean that Forth is a complex language.
- AnimalMuppet 8y ago
  Depends on what library they're from. Is the STL part of C++? Sure, it's a library, but it's a standard library - it should be there in every conforming implementation. Personally, I think of that as part of the language. Is some vendor's RS232-port-handling library part of C++? I would say no. In the same way, I think that Java's standard library is part of the language, and is in fact the strongest selling point of Java.
dwohnitmok 8y ago
Those are part of the standard library rather than the language itself though. You can (and a lot of people do) define and use your own standard library instead (hmmm... maybe a rabbit hole of its own? Although it seems companies with legitimate business needs do this as well so who knows).
dpratt71 8y ago
I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/GHC-Base.html#%24 https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/...).
- wtracy 8y ago
  Even if the operators themselves don't count as "part of the language", the complex precedence rules around them certainly should.
  - dwohnitmok 8y ago
    In what way? Those are defined as part of the operator. I usually parenthesize them anyway just like I would for an equation.
- village-idiot 8y ago
  On the whole, I consider user-defined infix operators to be a huge mistake. While the few common ones are great, the ability for every single library creator to add their own infix operator turns into a mess in the long run.
  - gowld 8y ago
    They fine inside a limited domain-specific scope, just don't go importing operators from many libs willy-nilly.
    - village-idiot 8y ago
      It’s very hard to convince people to keep them in that limited scope.
icc97 8y ago
I agree that this is one of the things that makes Haskell harder/scarier to learn, but I don't think that it makes it bigger.
vmchale 8y ago
None of these are remotely obscure unless you don't know functional programming.
Learn2win 8y ago
There are just functions.

by wtracy 8y ago

jhayward 8y ago

Those are mostly library functions, not part of the language. It doesn't seem any more reasonable to use them to declare Haskell a complex language than it would to have the existence of, say, a linear algebra library providing mathematical operators for Forth mean that Forth is a complex language.

AnimalMuppet 8y ago
Depends on what library they're from. Is the STL part of C++? Sure, it's a library, but it's a standard library - it should be there in every conforming implementation. Personally, I think of that as part of the language. Is some vendor's RS232-port-handling library part of C++? I would say no. In the same way, I think that Java's standard library is part of the language, and is in fact the strongest selling point of Java.

dwohnitmok 8y ago

Those are part of the standard library rather than the language itself though. You can (and a lot of people do) define and use your own standard library instead (hmmm... maybe a rabbit hole of its own? Although it seems companies with legitimate business needs do this as well so who knows).

dpratt71 8y ago

I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/GHC-Base.html#%24 https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/...).

wtracy 8y ago
Even if the operators themselves don't count as "part of the language", the complex precedence rules around them certainly should.
- dwohnitmok 8y ago
  In what way? Those are defined as part of the operator. I usually parenthesize them anyway just like I would for an equation.
village-idiot 8y ago
On the whole, I consider user-defined infix operators to be a huge mistake. While the few common ones are great, the ability for every single library creator to add their own infix operator turns into a mess in the long run.
- gowld 8y ago
  They fine inside a limited domain-specific scope, just don't go importing operators from many libs willy-nilly.
  - village-idiot 8y ago
    It’s very hard to convince people to keep them in that limited scope.

icc97 8y ago

I agree that this is one of the things that makes Haskell harder/scarier to learn, but I don't think that it makes it bigger.

vmchale 8y ago

None of these are remotely obscure unless you don't know functional programming.

Learn2win 8y ago

There are just functions.