[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video

Chris Kuklewicz haskell at list.mightyreason.com
Fri Nov 24 17:30:53 EST 2006

Simon Peyton-Jones wrote:
> I have also toyed with adding
>         retryWith :: IO a -> STM ()
> The idea here is that the transction is undone (i.e. just like the 'retry'
combinator), then the specified action is performed, and then the transaction is
retried. Again no atomicity guarantee. If there's an orElse involved, both
actions would get done.
> Unlike onCommit, onRetry adds new power.  Suppose you have a memory buffer, with an STM interface:
>     getLine :: Buffer -> STM STring
> This is the way to do transactional input: if there is not enough input, the
transaction retries; and the effects of getLine aren't visible until the
transaction commits. The problem is that if there is not enough data in the
buffer, getLine will retry; but alas there is no way at present to "tell"
someone to fill the buffer with more data.
> onRetry would fix that.  getLine could say
>     if <not enough data> then retryWith <fill-buffer action>
> It would also make it possible to count how many retries happened:
>    atomic (<transaction> `orElse` retryWith <increment retry counter>)
> I have not implemented either of these, but I think they'd be cool.
> Simon

After seeing how close I could come to creating onRetry/retryWith I have a
question about the semantics of your idea for retryWith.

Normally after a retry the STM block is rolled back and put to sleep and will
only be awakened and re-executed if one of the STM variables it had read from is
committed to by a different STM block.

What about retryWith ?  Will the STM block be put to sleep under the same
conditions?  Can the IO action given to retryWith include commits to STM variables?

More information about the Haskell-Cafe mailing list