The Revenge of Finalizers

[Simon Marlow]

> > However in general I think we can hide some of the horribleness from
> > the user:
> 
> > modify2IORefs :: IORef a -> IORef b -> (a -> b -> (a,b,c)) -> IO c
> > [horrible code deleted]
> 
> And if they need to update 3 IORefs or a list of IORefs?
> 
> Writing code like that yourself and getting it right and portable
> between compilers seems to be ludicrously hard.
> 
> I can't tell if that code is right (my gut says no).  Worse though, I
> don't even know what semantic framework to use to reason about it if
> we want to be sure the code will work in the presence of strictness
> analyzers, eager evaluation, parallel evaluation, fully-lazy
> evaluation, etc.  Operational reasoning and reasoning by example
> struggle with such a task.

I agree.

However, I think we're trying to solve a problem that doesn't exist yet.
All the libraries we have which are affected can be fixed by using
atomicModifyIORef, and even if one were to arrive which can't be fixed
in this way, the chances that someone would also want to use it from a
finalizer are rather low.

I think a more pressing problem is whether Haskell finalizers can be
implemented in Hugs properly - any thoughts on the problem I raised
earlier?

Cheers,
	Simon

PS. I've implemented atomicModifyIORef in GHC and am testing it now.