[Haskell-cafe] IO and State (was Re: [Haskell] Re: Global Variables and IO initializers)

[Graham Klyne]

At 10:38 08/11/04 -0800, Iavor S. Diatchki wrote:
>It is not (should not be?) the case that IO = ST RealWord, as IO is not a 
>state monad as we understand it.
>In a state monad, the changes to the state are all in the program, i.e. 
>one can always
>point to the part of the program that modified the state.
>On the other hand, the "state" of the RealWorld can change on its own,
>without anything in the program affecting it.
>I guess this is similar to "volatile" state in C.
>For example, one might expect the following rule in a state monad:
>
>do x <- readSTRef r
>     y <- readSTRef r
>     f x y
>=
>do x <- readSTRef r
>     f x x
>
>But this is not true for the IO monad, as for example reading a file twice 
>does not guarantee
>that you will get the same result, even if no part of the program ever 
>wrote to the file.
>
>Now the above law already doesn't hold when all GHC extensions are used,
>as when concurrency is present we cannot assume that nobody modified the 
>state concurrently.
>As a result all pointers in GHC probably behave as if they were 
>"volatile", which is not very nice.

Eek!  I find this most worrisome.  And I'm not sure that I agree.

I thought that part of the reason for having a monad that it was threaded 
in a useful way through the path of a *single* computation (expression 
evaluation).  If concurrent activities can change that, then I sense that 
they're breaking something quite fundamental in the way Haskell should work.

e.g. in a sequence like:

   v :: SomeMonad
   v = do { e1 ; e2 ; e3 }

Then I think that exactly the monad created by e1 is passed to e2, and the 
result of e2 passed to e3, without any visible external interference under 
any circumstance.  Concurrency, as I understand it should apply to Haskell, 
would allow different elements of that computation to be performed in 
different threads/processes, but the overall result of the computation 
should not be changeable.  Put another way, the graph reduction model for 
evaluating a Haskell program should not change, just the mechanics actual 
processes (or processors) actually perform the reduction steps.

Or am I really overlooking something here?

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact