On 4/23/08, David Roundy <[EMAIL PROTECTED]> wrote: > I'm confused as to how your retryUntil gains you anything. If any of the > TVars used in the expensive_computation change while waiting for a retry, > then the expensive_computation will need to be done again. If none of them > change, then we can skip the expensive_computation.
Does the STM runtime do this? > i.e. how does your broken function using retryUntil differ from the > following? > > broken = atomically $ do > v <- expensive_computation :: STM (TVar Int) > vv <- readTVar v > unless (vv > 50) retry If the STM runtime does the optimization you suggest, it's not different at all. But consider this computation: > -- non-primitive retryUntil: > retryUntil v p = do > x <- readVar v > unless (p x) retry > > broken2 = atomically $ do > (v1, v2) <- expensive_computation :: STM (TVar Int, TVar Int) > retryUntil v1 (> 50) > x <- expensive_computation2 :: STM Int > retryUntil v2 (> x) If v1 succeeds and v2 fails, then v1 changes to some other value > 50, I am sure that the STM runtime as it stands now will re-run expensive_computation2. -- ryan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
