Simon PJ's "Tackling the awkward squad" has an excellent (and highly
readable) account of IO, if you want a more precise treatment. (It also
covers concurrency, exceptions, and FFI to a degree.)
http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/
It's hard to choose a favorite amongst Simon's writings, but this one
stands out in my opinion in its lucidity, and how clear it makes these
"awkward" parts of Haskell, without giving up any rigor.
-Levent.
On Thu, Apr 16, 2015 at 6:06 PM, David Feuer
Others have already discussed this in terms of GHC's model of IO, but as Tom Ellis indicates, this model is a bit screwy, and not really the best way to think about it. I think it is much more useful to think of it in terms of a "free monad". That is, think about the `IO` type as a *data structure*. An `IO a` value is a sort of recipe for producing a value of type `a`. That is,
data IO :: * -> * where ReturnIO :: a -> IO a BindIO :: IO a -> (a -> IO b) -> IO b HPutStr :: Handle -> String -> IO () HGetStr :: Handle -> IO String ....
And then think about the runtime system as an interpreter whose job is to run the programs represented by these IO values. Perhaps I need to be more specific.
main = do a <- getLine b <- getLine
Can we say "a" absolutely always receives the first line of input and if so what makes this the case rather than "b" receiving it ? Or do things need to be slightly more complicated to achieve this ?
Sorry it's just the engineer in me. I think once I've got this clear I'll be happy to move on.
Jon
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe