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

Judah Jacobson wrote:

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?

I don't think oneshots are very good for open witness declarations (such as the open exceptions I mentioned originally), since there are pure functions that do useful things with them. Not sure about TVars either, which operate in the STM monad. Would you also need a oneshotSTM (or a class)? -- Ashley Yakeley

Judah Jacobson wrote:

I think you're saying that you want to write "w <- newIOWitness" at the top level, so that w can then be referenced in a pure function. Fair enough. But newIOWitness's implementation requires writeIORef (or an equivalent), which is not ACIO, right?

newIOWitness is very like newUnique. In both cases, the internal implementation updates an MVar to make them unique. Internally the open-witness package would use unsafeIOtoACIO (just as it already uses unsafeCoerce), but an exposed newIOWitnessACIO would be safe.

oneshot uniqueVar :: IO (TVar Integer) uniqueVar =< atomically $ newTVar 0 -- alternately, use newTVarIO

uniqueIntSTM :: IO (STM Integer) uniqueIntSTM = uniqueVar >>= \v -> return $ do n <- readTVar v writeTVar v (n+1) return n

getUniqueInt :: IO Integer getUniqueInt = uniqueIntSTM >>= atomically

This complicates the purpose of STM, which is to make composable STM transactions. I would rather do this: uniqueVar :: TVar Integer uniqueVar <- newTVarACIO uniqueInt :: STM Integer uniqueInt = do n <- readTVar uniqueVar writeTVar uniqueVar (n+1) return n AFAICT, one-shots are less powerful and just as complicated as an ACIO monad. -- Ashley Yakeley

Judah Jacobson wrote:

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

I've been wondering about something like this too (in some way just have a oneShot or runOnce and the *only* thing in ACIO as a magic primitive). runOnce :: IO a -> ACIO (IO a) It would certainly simplify the ACIO monad :-), but I'm not sure it's really as flexible. Provided newMVar can be ACIO then this can be implemented directly (doesn't need to be a primitive). But we can't go the other way round (use runOnce to create genuine top level MVars or channels say). Does that matter? Probably not for monadic IO code. It's not a huge inconvenience to write.. do ... thing <- getThing foo thing vs.. do ... foo thing -- thing is at top level But for top level non monadic code/expressions/data structures I can see a certain convenience in having thing as top level identifier if possible, which it often won't be anyway I guess for other reasons (like it's creation and initialisation requires real IO). So I don't have any particularly strong opinion either way. In practice if thing (or getThing) is to be exported then it would probably be prudent to assume creation and initialisation might require real IO at some point in the future even if they don't right now, so you'd export getThing (= return thing) anyway, rather then have an exported thing dissappear from the API at some point. My 2p.. Regards -- Adrian Hey

Adrian Hey wrote:

Maybe it would be safest to just say anything with a finaliser can't be created at the top level.

Do you have an example of something that is correctly ACIO to create, but has a problematic finaliser? -- Ashley Yakeley

On Tue, Aug 26, 2008 at 08:07:24AM +0100, 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.

If the finalizer is also in the weaker form of ACIO (ACIO under the no more references exist to its argument presumption, maybe called 'linearity condition' or something?), then it shouldn't matter at all. I can't think of any finalizers that don't obey this property that wern't problematic under the old model to begin with. John -- John Meacham - ⑆repetae.net⑆john⑈