Why isn't the list monad method for `>>` defined as `flip const`?

问题

Is there some reason why the Prelude doesn't define the list monad like this? (Note the non-standard implementation of >>.)

instance  Monad []  where
    m >>= k          = concat (map k m)
    m >> k           = k                 -- a.k.a. flip const
    return x         = [x]
    fail s           = []

I tried checking this against the monad laws, but they don't mention >>. The Monad class definition is this:

m >> k = m >>= \_ -> k

which in the [] instance would translate to this:

concat (map (\_ -> k) m)

which is of course not equivalent to flip const—they produce an obviously different results for, say, [1..5] >> return 1. But it's not clear to me whether this default definition is a law that instances of Monad must respect, or just a default implementation that satisfies some other law that the flip const implementation would also satisfy.

Intuitively, given the intent of the list monad ("nondeterministic computations"), it seems like the alternative definition of >> would be just as good, if not better thanks to pruning branches that are guaranteed to be equal down to just one. Or another way of saying this is that if we were dealing with sets instead of lists, the two candidate definitions would be equivalent. But am I missing some subtlety here that makes the flip const definition wrong for lists?

EDIT: ehird's answer catches a very obvious flaw with the above, which is that it gets the wrong intended result for [] >> k, which should be [], not k. Still, I think the question can be amended to this definition:

[] >> k = []
_ >> k = k

回答1:

a >> b must always be equivalent to a >>= const b; it's only in the Monad class so that you can define a more efficient (but semantically equivalent) version. That's why it's not part of the monad laws: it's not really part of the definition of a monad, only the typeclass (like fail).

Unfortunately, I can't find anywhere in the documentation for the base package where this is stated explicitly, but I think older versions may have defined (>>) outside of the Monad typeclass.

For what it's worth, your definition of (>>) breaks the list monad's use for nondeterministic computations. Since [] is used to represent failure, [] >> m must always be []; you can't continue on after you've exhausted all possible branches! It would also mean that these two programs:

do { m; ... }
do { _ <- m; ... }

could differ in behaviour, since the former desugars with (>>) and the latter with (>>=). (See the Haskell 2010 Report.)

回答2:

Because ma >> mb just is shorthand for ma >>= \_ -> mb. If >> were defined as flip const just in the case of lists, then ma >> mb wouldn't run the computation in ma at all if ma is a list, which would be very confusing.

As for why it isn't defined as flip const in general, well, the present semantics of >> makes it able to sequence effects where you don't care about their results, which is often useful.

回答3:

Your definition of >> breaks the Monad associativity law:

newtype B a = B { unB :: [a] }

instance Monad B where
  m >>= f = B . concatMap (unB.f) $ unB m
  (>>) = flip const
  return a = B [a]

case1 = B [1,2,3] >>= (\_ -> B [4,5,6] >> return 1)
case2 = (B [1,2,3] >>= \_ -> B [4,5,6]) >> return 1

main = do
  print $ unB case1
  print $ unB case2

The two cases above differ in their associativity, but yield different results.

来源：https://stackoverflow.com/questions/10490852/why-isnt-the-list-monad-method-for-defined-as-flip-const