[Haskell] threading mutable state through callbacks

[Vincenzo Ciancia]

On Tuesday 12 October 2004 21:25, Adrian Hey wrote:
> I've never really understood what people mean by things being
> "inside" and "outside" the IO monad :-(

Inside the IO monad means "correctly sequenced together with other IO 
operations which are inside the IO monad". It's called "inside" since 
people (me at least) view the IO monad as a one-way thingy where you 
have only an entry point (the main function), so you can either be 
"inside" and correctly sequenced, or "outside" like an 
unsafeInterleaveIO computation.

>
> Assuming from Vincenzos original example that ..
>
> someAction :: SomeType -> IO Thing
>
> then in your example..
>
> z :: IO Thing
>
> So z is a perfectly ordinary value. The someAction that creates y
> will be executed only once, as soon as the value of y is needed,
> which (assuming someAction is strict) will be as soon as the value of
> z is needed, I.E. "Whenever"

The objection was for cases like

x :: Int <- someIOAction
y :: Int = x + 1

Note that both have Int type but the second is a pure value while the 
first is the result of a computation.

I think that the easy way would be to allow a keyword like a top-level 
let, where a program like

let x1 <- action1
...
let xn <- actionn

main = other_actions

is equivalent to

main = do
 x1 <- action1
 ...
 xn <- actionn
  other_actions

top-level "ordinary" bindings can't see x1...xn, and order of evaluation 
is imposed. Or else you can simply say that NO binding, even x1...xn 
can see the others. This could be done with a special keyword and 
source-code preprocessing; ok, I am sorry for such a naive point of 
view - I mean the whole post :)

V.