Re: [Haskell-cafe] Re: [Haskell] Top Level <-

On Tue, Aug 26, 2008 at 01:14:34AM -0700, Judah Jacobson wrote:

On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey 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...

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).

Actually, due to the definition of ACIO, there is no difference between the two (for actions actually in ACIO). It was formulated to have this property. both implementations (executing them before the program is run, or on first call) and ways of thinking about things are valid and will be indistinguishable for all proper ACIO actions. note, you can implement oneshot IO actions on top of ACIO top level actions, but not the reverse. I think ACIO is cleaner overall, since we have a nice formal definition of when ACIO actions are valid without having to invoke the more complicated IO monad. John -- John Meacham - ⑆repetae.net⑆john⑈