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

[Adrian Hey]

John Meacham wrote:
> I forgot who came up with the original ACIO idea, but I'd give them
> props in the manual if they wish.

I think this is based on Ian Starks message..
  http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html

> Yeah, this sounds like a great idea. there were a whole lot of issues
> dealing with finalizers and concurrency, and restricting them in some
> way similar to ACIO might be good... however, you want something a
> little weaker than ACIO I think. it must satisfy the ACIO conditions,
> but _may_ assume its argument (the item being collected) is never
> referenced again. hence something like 'free' is okay which wouldn't be
> if other references to the object exist. do you think that is 'formal'
> enough of a description? seems clear enough if ACIO is well defined which I
> think it is.

Yes, now I cast my mind back that was something that was troubling me.
Clearly the one thing you're most likely to want to do in a finaliser
is free some external resource, which certainly wouldn't be ACIO
ordinarily. But as you say, giving sane semantics and type safety
to finalisers is very tricky indeed.

I can't help thinking that semantically finaliser execution should be
treated like some kind of external event handling, like an interrupt.
Not sure what that should be properly, but I think finalisers should
be the same.

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.

Regards
--
Adrian Hey