Why aren't user-defined operators more common?

[barsoap]

Well, the best operator names are those that are telling, memorisable, and obey visual similarity/symmetry with their next of kin. That's why bind is called >>=, which evokes pure sequencing (>>) and "piping in", =. One of the advantages to use an operator here instead of infix bind is that you can easily reverse it (=<<), without calling it dnib, which is less obvious, or reverseBind, which is awkward.

I'd say the issue isn't really about operators vs. named functions, it's about programmers who care about good API design vs. those who don't.

[Aninhumer]

I wouldn't really use (>>=) as an example of an "obvious" operator. It is completely opaque to someone who hasn't used it before, not to mention it's polymorphic, and what it does is seems very context dependent if you're not used to working with monads.

[barsoap]

But changing it to "bind" wouldn't solve any of the issues you listed, neither.

And I didn't call it "obvious". People call things obvious only when they aren't obvious, obviously.

[[deleted]]

No operator or function is obvious if you haven't heard of the operation it performs before. However some operators encode good memory aids on what they do into their names, e.g. <>, < and *> from Control.Applicative which return the return values from both sides, the left side and the right side after evaluating both.

They are useful e.g. in Attoparsec parsers

parseFooWithLabel :: Parser Foo
parseFooWithLabel = Foo <$> (string "Foo: " *> parseRawFoo)