atom = many digit
<|> identifier
<|> stringLiteral
<|> between (char '(') (char ')') expression
I can't imagine any way this would look better with a name instead of the <|> operator. You could write it something like: atom = many digit
`or` identifier
`or` stringLiteral
`or` between (char '(') (char ')') expression
but that's no clearer and a bit harder to follow. With a much longer identifier than "or", it would be completely unreadable. If you had to make "or" prefix (the `` let you use a normal function in infix position), it would be even less readable. Combine the two (a longer, prefix identifier) and you have an even bigger mess!The operators let you see the structure of an expression at a glance. You don't have to read the whole thing to figure out what's going on. Moreover, the <|> symbol is pretty intuitive--it's clearly based on | which usually represents some sort of alternation.
> sanderjd: I do think Parsec would be better off if "<|>" were something like "parsecOR"
Do you think perhaps some people think about functions visually while others think about them auditorily?
An IDE could easily render function names however the human reader wants. The option whether to render function names as names or symbols would be customizable, just like the display colors for various element types are.
Within each option, there's further choices. For names, there could be a choice between various natural languages. For symbols, it could be restricted to ASCII e.g. <|>, or full Unicode, e.g. | enclosed by a non-spacing diamond.
\ a b c -> a >= b && b <= c || a /= c
gets rendered as: λ a b c → a ≥ b ∧ b ≤ c ∨ a ≢ c
However, this is a bit of a pain to do in general. It works well for common functions and syntax elements, but has to be built into the editor. Doing it more generally would require the author of the initial function to come up with multiple different names for it, which sounds unlikely.I will say that in my opinion, the alternative in the reply above this (which I can't reply to) looks fairly nice, is clearer, and not even a little bit harder to follow. But I'll allow that as a very casual Haskell programmer, my opinions about Haskell are probably not particularly valid.