[Haskell-cafe] Re: [Haskell] Top Level <-
john at repetae.net
Tue Aug 26 20:34:37 EDT 2008
On Tue, Aug 26, 2008 at 01:14:34AM -0700, Judah Jacobson wrote:
> On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey <ahey at iee.org> 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:
> 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 Meacham - ⑆repetae.net⑆john⑈
More information about the Haskell-Cafe