[Haskell] IORef sharing

[Brandon S. Allbery KF8NH]

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] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH