On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey
But from a top level aThing <- someACIO point of view, if we're going to say that it doesn't matter if someACIO is executed before main is entered (possibly even at compile time) or on demand, then we clearly don't want to observe any difference between the latter case and the former (if aThing becomes garbage without ever being demanded).
Maybe it would be safest to just say anything with a finaliser can't be created at the top level. We can always define an appropriate top level "get" IO action using runOnce or whatever.
I've been wondering: is there any benefit to having top-level ACIO'd <- instead of just using runOnce (or perhaps "oneshot") as the primitive for everything? For example: oneshot uniqueRef :: IO (MVar Integer) uniqueRef =< newMVar 0 It was also suggested in that wiki page: http://haskell.org/haskellwiki/Top_level_mutable_state#Proposal_4:_Shared_on... Those proposals eliminate the need for creating an ACIO monad and enforcing its axioms, since one-shot actions are executed in-line with other I/O actions (rather than at some nebulous "before the program is run" time). So, in the context of top-level initializers, does ACIO offer something beyond what oneshot provides on its own? If not, I prefer the latter since it seems like a much simpler solution. Best, -Judah