On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey <[EMAIL PROTECTED]> wrote: > > > 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-demand_IO_actions_.28oneShots.29 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
