| In many useful cases, such as the getLine example, the Y action will have its
| own atomic {} block. In which case the semantics of when it is allowed to
| re-attempt X are what is important. If you require (Y) to complete before
| re-attempting (X) then you get an infinite regression where every (atomic
block)
| fails with (retryWith (next atomic block)), and nothing is ever re-attempted.
| This is why "retryWith Y" meaning rollback X and do "Y >> atomic X" is the
wrong
| implementation.
I don't agree. I think it's quite reasonable. Not many atomic blocks will
finish with retryWith. Of course there is a possibility of an infinite loop,
but we already have that: f x = f x. Of course, Y can always choose to do a
forkIO, but it shouldn't hav to.
For me the only difficulty is the implementation. We'd like to block X on the
TVars it read (as usual), *unless* executing Y wrote to any of them. That
requires a bit more cleverness in the commit code, but not a great deal I think.
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
