Conditional evaluation might be a use-case of monads, but that doesn't make them synonymous. "getLine >>= putStrLn" (read a line from stdin, write it to stdout) is a fine Haskell expression of the IO () type, but nothing in it resembles a choice. Monadic expressions can be extremely, boringly linear.

Are you sure? Of all the messages the program could have printed, of all the I/O actions imaginable, the program somehow made a choice that was not hard-coded, but based on my input! The expression multiplexes one I/O action (what to print) based on the result of another (get input from user).

That's choice!

Edit: Just realised what might be confusing. putStrLn is not an I/O action in and of itself. It's a function that multiplexes on several I/O actions based on the input value. However, crucially, that input value is pure, and thus can only be hard-coded (maybe through a bunch of indirections, but ultimatedly statically determinable.) Monadic bind is what lets us depend on another I/O result.

You're stretching. :) But even if I accept the point you're making here, that doesn't make monads synonymous with choice. Every choice is not a monad, and every monad is not a choice. This is far too reductionist. Is there no choice involved in monoids, arrows, for example? What makes monads special in this regard? And what about I/O in languages that cannot implement these concepts?

> Monad is practically synonymous with choice.

Arrows also allow you to "multiplex on whatever is represented by a thing to choose a different thing" so you'll have to be more precise!

Sure, so the way I understand it, a monad is a special type of arrow, so that's kille saying "You also live in France, so you'll have to be a bit more precise than Paris", no? I.e. both claims are equally true.

I think you have that the wrong way round.

please do not talk about Arrows publicly; it has done enough damage