Simon Marlow wrote:
[...] There was this, from Dean Herrington:
http://haskell.cs.yale.edu/pipermail/ffi/2002-October/000940.html
I don't have any strong feelings (I rarely do, where names are concerned).
I would be happy with his proposal. We can leave the IORef stuff in IOExts as it is and use the new signatures and functions in Data.IORef. The only annoying thing is the signature of Data.IORef.modifyIORef, but we could declare the old signature as a bug... :-]
Actually, looking at the proposal again, I don't think I like the changes to the MVar interface. atomicModifyMVar seems strange, because modifyMVar is already atomic. We have to be careful about trying to smooth over differences between IORef and MVar where those differences are real and important. I don't mind changing modifyIORef to have a signature which is more similar to modifyMVar, and I think adding atomicModifyIORef_ is a good idea (although it needs a new primitive if we're to take advantage of its efficiency over atomicModifyIORef). Summary: - make modifyIORef's type match modifyMVar - add modifyIORef_ - add atomicModifyIORef and atomicModifyIORef_ Cheers, Simon