This code (taken from Learn You A Haskell):
main = do putStr "Hey, "
putStr "I'm "
putStrLn "Andy!"
apparently desugars to
main = putStr "Hey, " >>=
(\_ -> putStr "I'm " >>=
(\_ -> putStrLn "Andy!"))
Which, as I understand it can be interpretted as saying "In order to putStrLn "Andy!" I first need to putStr "I'm ", and in order to do that I first need to putStr "Hey, ";
I disagree with this interpretation, which is annoying because the compiler obviously doesn't and leaves me feeling confused. The problem I have with it is that the lambdas ignore their arguments, during lazy evaluation isn't this sort of thing supposed to be recognised and short-circuited?
Also, sure, the binding returns an IO action, and when that IO action falls into main it gets executed. But what's to stop it from printing "Hey, Andy!I'm "? I suspect it's whatever bind is doing.
Also, how does an IO action of type "IO ()" carry enough information to allow the runtime system to print "Hey, I'm Andy!"? How is that IO () different to an IO () than prints "Hello World!" or writes to a file?
Consider another, from the wikipedia page for monad:
Sugared version:
do
putStrLn "What is your name?"
name <- getLine
putStrLn ("Nice to meet you, " ++ name ++ "!")
Desugared version:
putStrLn "What is your name?" >>=
(\_ ->
getLine >>=
(\name ->
putStrLn ("Nice to meet you, " ++ name ++ "!")))
Similar story here.
I think I just need to see the definition of bind for IO and then it will be all clear. Something else that would help a lot is if someone could help me step through how the program actually gets evaluated and identify the exact moments when the side effects occur.
Read the "Tackling the awkward squad" paper by Simon Peyton Jones.
For related questions, see
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 above
main,
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With