On 24 Jan 2005, at 10:32, Keean Schupke wrote:
Right, but we are dealing with the type system here. Remember Haskell monoids are functors on types, not on values ... (ie the base objects the 'category theory' is applied to are the types not the values)...
Therefore we only consider the types when considering Monads.
This is not true. Here are the three monad laws as written on the nomaware site: 1. (return x) >>= f == f x 2. m >>= return == m 3. (m >>= f) >>= g == m >>= (\x -> f x >>= g) Taking rule 1, we do not simply mean that return x >>= f and f x have the same type. (This is obviously true). We require that they are equal as values of the type m a. In the case of IO, this means that they perform the same action before yielding the same result. Example: return "hello" >>= putStrLn this does not only have the same type as putStrLn "hello", and return the same value (), but it also carries out exactly the same actions. If it was simply enough that it have the same type, then it would be 'good enough' if return "hello" >>= putStrLn had the same effect as putStrLn "goodbye" ...which has the same type, and the same return value. Aside: you said a couple of messages ago:
Yes it is, side effects are quite clearly not counted. The value of (putStrLn "Hello" >> mzero") is mzero.
This concept of 'value' only makes sense in some monads. In the List monad there can be many 'values' of a computation. It just happens that IO 'returns' a 'single value' all the time. Jules