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"?
Jules
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
