Talk:What a Monad is not

Nicolas Pouillard Comments

I disagree with: "So ordering is not in any way essential to what a monad is."

There is commutative monads, great! Other than that the order is important. Moreover there is nothing wrong to see >>= as a sequencing operator.

I also disagree the "IO is impure" paragraph: Indeed only IO will trigger visible side effects, but this is only due to the common evaluation of IO primitives. Moreover I would say that only the runtime system is impure because it does reduce 'main :: IO ()', other than that we are just building a computation plan in a pure way.

Although I agree that the common issue is too mix monad and impurity, and the impurity question is only releated to IO.

---

Kris Nuttycombe's addendum:

I concur with the analysis above; furthermore, there is a way in which I think that monads express the essence of sequentiality; they express *causality* as data dependency.

Given 'f a' and 'a -> f b' there is no way to obtain an 'f b' without the availability of the value 'a'. The fact that the associative law permits you to rearrange independent clauses within a do block (clauses that do *not* have a data dependency) does not mean that the data dependency doesn't exist. Similarly, when you automatically derive an Applicative instance for a given monad, it will necessarily produce the sequentiality of effects implied by the parent monad.

By contrast, I look to the 'zip' formulation of the applicative functor, 'f a -> f b -> f (a, b)'. It is clear from the type that there is no data dependency between these two effects, and so the order of effects should ideally be able to be ignored. Of course, this is not in practice the case for many applicative functors, including at least the set of types for which Monad instances exist. However, I think that this is an important property that should get more attention in the Haskell community; commutative applicative functors (which should be considered equal to monads in importance) express the essence of parallelizable computation, whereas monads express the essence of those computations which are necessarily sequential as a consequence of data dependency.

"Monads are not values"

Yes they are! But they are not of the type of their arguments. For instance "return 3" is a value that has (or can have) type "IO Int". But it is not a value of type Int. —Ashley Y 23:44, 23 November 2009 (UTC)

[Nicolas Pouillard]: The point was that the IO monad is not a value, of course there is values of type "IO Int". However the record/dictionary is a value and one could say that it is the monad.

In what sense is Maybe commutative?

It seems to me that Maybe is not really a commutative monad, as claimed here and at Monad.

do
  x <- Nothing
  y <- undefined
  return (x+y)

produces Nothing whereas

do
  y <- undefined
  x <- Nothing
  return (x+y)

produces undefined.

Note that the Reader monad (also mentioned in Monad) does appear to be commutative. --Dfeuer (talk) 17:15, 19 June 2014 (UTC)