On 2008 Oct 27, at 20:25, Rodney D Price wrote:
Okay... However, when I use IO in a Haskell program, the response is usually pretty snappy. It's not as if the Haskell runtime is hanging around, waiting for some time in the future when it might be appropriate to do IO. It happens right now. Yet the literature gives the impression that the IO monad in particular is a clever trick to preserve referential transparency by gathering up all the IO actions, but not necessarily actually *performing* them. Then the Haskell runtime holds its nose and *performs* them when necessary.0
The *conceptual* model for the IO monad is that "main" returns a big IO action which is then evaluated by the Haskell runtime.
As a practical matter, this usually behaves the same as if <- actually did evaluation. (It doesn't. It binds monadic expressions together, and is a convenient way to use the (>>=) operator.) The one difference is its interaction with Haskell equations (a = b); since those are more or less macro definitions, assigning e.g. an expression of type IO String to such a "macro" will cause the expression to be substituted wherever the "macro" is used.
IO is a very atypical monad, by the way. Someone pointed you earlier to the "IO Inside" page, which describes the internal tricks that make IO work. I prefer to think of IO actions as partially applied functions, with the missing argument being a "RealWorld" that is hidden inside the IO monad. (think: IO a = State RealWorld a. This isn't quite correct because the state also has IORefs inside it.)
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
