[Haskell] threading mutable state through callbacks

Jules Bean jules at jellybean.co.uk
Tue Oct 12 17:19:25 EDT 2004

On 12 Oct 2004, at 20:25, Adrian Hey wrote:

> On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
>> On 12 Oct 2004, at 14:08, Adrian Hey wrote:
>>>> x <- someAction
>>>> y <- someAction(x)
>>> I would say keep things as they currently are with the 
>>> unsafePerformIO
>>> solution, I.E. Order unspecified, the action that creates a 
>>> particular
>>> top level thing is executed only once, when the value of thing is
>>> demanded (perhaps not at all).
>> Also consider the case of
>> z = someAction(y)
>> Here z is a value outside the IO monad, calculated using a function
>> outside the IO monad, based on a value (y) which also lies outside the
>> IO monad... What sane semantics will explain when the actions which 
>> led
>> to the value y should be taken?
> I've never really understood what people mean by things being "inside" 
> and
> "outside" the IO monad :-(
> Assuming from Vincenzos original example that ..
> someAction :: SomeType -> IO Thing
> then in your example..
> z :: IO Thing

Yes, I wrote it wrong. I meant

z = someFunction(y)

'Inside the IO Monad' means having some type IO a. Outside it means 
having a type not of this form. At least, that's what I meant. 
[Vincent's explanation is another way of looking at it]

> This still leaves the uncertainty of exactly when the creation occurs,
> but this is a minor issue IMO. We have the same problem with finalisers
> and any concurrent code. Either it just doesn't matter, or if it does
> then it's the programmers responsibility to use existing mechanisms
> (such as seq) to control things.

It does matter for general IO operations at the top level. Order 
doesn't matter in in any essential way for the particular case of 
newIORef, no.

> What I want is non-hack mechanism for creation of arbitrarily complex
> "things with identity" at the top level. I guess you could arrange that
> all such things were constructed at run time before executing main, but
> I don't see any real advantage in that.

Now it's my turn not to understand you. What is a "thing with identity"?


More information about the Haskell mailing list