Personal tools

Talk:What a Monad is not

From HaskellWiki

Jump to: navigation, search

1 Nicolas Pouillard Comments





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.

2 "Monads are not values"



3 In what sense is Maybe commutative?

It seems to me that
is not really a commutative monad, as claimed here and at Monad.
  x <- Nothing
  y <- undefined
  return (x+y)
  y <- undefined
  x <- Nothing
  return (x+y)
. Note that the
monad (also mentioned in Monad) does appear to be commutative.

--Dfeuer (talk) 17:15, 19 June 2014 (UTC)