Lazy evaluation and IO side effect confusion

Read the "Tackling the awkward squad" paper by Simon Peyton Jones.

For related questions, see

  • What does "pure" mean in "pure functional language"? ,
  • Is Haskell truly pure (is any language that deals with input and output outside the system)?
  • In what sense is the IO Monad pure?
  • Haskell: actual IO monad implementation, in different language?
  • Why does Haskell not have an I Monad (for input only, unlike the IO monad)?
  • References for learning the theory behind pure functional languages such as Haskell?

Take any such explanation including mine with a grain of salt - no hand-waving can replace a rigorous peer-reviewed paper, and the explanations are necessarily over-simplifications.

A very rough perspective is that >>= can be seen as a list constructor:

data IO = [Primitive]

and IO subsystem deconstructs the value of main and consumes that list. I.e. ``mainis just a list. So you may want to take a look at the definition of Haskell entry point abovemain,bind` is rather uninteresting.

You can also read papers on history of haskell and look at earlier versions of IO subsystem for insight of what is going on.

Also look at C language is purely functional satiric post by Conal Elliott.

The definition of functional purity is non-trivial and I remember a paper elaborating on the definition, but I don't remember the title.


Looking at IO in a real Haskell implementation will probably confuse more than it enlightens. But think of IO as being defined like this (this assumes you know GADTs):

data IO a where
    Return a :: IO a
    Bind :: IO a -> (a -> IO b) -> IO b
    PutStr :: String -> IO ()
    GetLine :: IO String

instance Monad IO where
    return = Return
    (>>=) = Bind

putStr :: String -> IO ()
putStr = PutStr

getLine :: IO String
getLine = GetLine

So when you evaluate a program (of type IO ()) all it does is to build a data structure of type IO () that describes how the interaction with the world will happen once you execute it. You can then imagine the execution engine being written in, e.g., C, and there is where all effects happen.

So

main = do   putStr "Hey, "  
            putStr "I'm "  
            putStrLn "Andy!"

is the same as

main = Bind (PutStr "Hey, ") (\ _ -> Bind (PutStr "I'm ") (\ _ -> PutStr "Andy!"))

And the sequencing of these comes from the way the execution engine works.

That said, I know of no Haskell implementation that actually does it this way. Real implementations tend to implement IO as a state monad with a token representing the real world being passed around (this is what guarantees sequencing), and primitives like putStr are just calls to C functions.


I think I just need to see the definition of bind for IO and then it will be all clear.

Yes, you should do that. It's actually quite easy, and if I remeber correctly it goes like

newtype IO = IO (RealWorld -> (a, RealWorld))

(IO f) >>= g = ioBind f g
    where
       ioBind :: (RealWorld -> (a, RealWorld)) -> (a -> IO b) -> RealWorld -> (b, RealWorld)
       ioBind f g rw = case f rw of
            (a, rw@RealWorld) -> case g a of
                IO b -> b rw

The "trick" is that every IO value is actually basically a function, but to evaluate it you would need a token of type RealWorld. There is only one instance that can supply such a value - the runtime system running main (and, of course, the function that must not be named).

Tags:

Functional Programming

Haskell

Lazy Evaluation

Side Effects

Recent Posts