Gregg Reynolds
getChar >>= \x -> getChar
An optimizer can see that the result of the first getChar is discarded
It isn't discarded. The first getChar results in a value of type IO Char, always and ever. Whether or not the Char inside the IO Char gets evaluated or not is another question... >>= could not care less about what you do to the values that are _inside_ the monad. If you look at the type (>>=) :: (Monad m) => m a -> (a -> m b) -> m b , you will find it hard to do much of significance to "a" and/or "b"[1] Whether or not a monad behaves strictly or lazyily wrt. to "m" depends on the definition of the functions that come with it: IO happens to be strict, [] to be lazy. This is nothing that messes with semantics, though, it celebrates them. [1] Well, you can pass them to id, seq or par, and replace them with undefined... -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.