<div>&gt; broken2 = atomically $ do<br>&gt;&nbsp; &nbsp;(v1, v2) &lt;- expensive_computation :: STM (TVar Int, TVar Int)<br>&gt;&nbsp; &nbsp;retryUntil v1 (&gt; 50)<br>&gt;&nbsp; &nbsp;x &lt;- expensive_computation2 :: STM Int<br>&gt;&nbsp; &nbsp;retryUntil v2 (&gt; x)</div>

<div>&nbsp;</div>
<div>Ah. I think I see now. I had thought you were trying to give more power to the primitive than you are.</div>
<div>&nbsp;</div>
<div>But I&#39;m still finding the example confusing, in that expensive_computation2 is in STM, and thus isn&#39;t pure. The point, I suppose, would rather be to assert that retryUntil v2 (&gt; x) depends on what v2 depends on, and what x depends on, but *not* on what v1 depends on, and thus to retry only when the appropriate portion of the dependency tree changed.</div>

<div>&nbsp;</div>
<div>However, in this case, that still doesn&#39;t buy you anything, I think, because from the information given, one can&#39;t disentangle what v1 and v2 depend&nbsp;on?</div>
<div>&nbsp;</div>
<div>I hope I&#39;m somewhat closer to the mark here.</div>
<div>--S<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 4/23/08, <b class="gmail_sendername">Ryan Ingram</b> &lt;<a href="mailto:ryani.spam@gmail.com">ryani.spam@gmail.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 4/23/08, Sterling Clover &lt;<a href="mailto:s.clover@gmail.com">s.clover@gmail.com</a>&gt; wrote:<br>&gt; But expensive_computation2 is in STM. This means that it *should* be rerun,<br>
&gt; no? Between the first run and the retry, the result of<br>&gt; expensive_computation2 may well have changed.<br><br>Ah, but that&#39;s not true; the main &quot;good thing&quot; about retry is that you<br>don&#39;t have to keep running the computation; instead you wait until<br>
something that you accessed in your transaction log changes and -then-<br>you rerun it.&nbsp;&nbsp;Right now the transaction log for &quot;retry&quot; only contains<br>&quot;read from variable X&quot; (for some list of variables).&nbsp;&nbsp;But it could<br>
instead contain &quot;read from variable X&quot; and &quot;read from variable X using<br>retryUntil with predicate p which gave result True&quot;.&nbsp;&nbsp;Then we have a<br>&quot;smarter&quot; log which can use the pure predicate p to give more<br>
information about whether or not the whole transaction can run or<br>whether it is just guaranteed to fail again.&nbsp;&nbsp;If we know a transaction<br>is guaranteed to fail, we can skip running it because we know it will<br>not commit.<br>
<br>Given the semantics of retryUntil, it is impossible that changing v1<br>affects the results of running this STM computation -unless- it or<br>something else prior in the computation read from v1, or the result of<br>the predicate changes.<br>
<br>No spooky-action-at-a-distance is possible.&nbsp;&nbsp;David&#39;s more general<br>&quot;subatomically&quot; primitive would achieve the same results; the proof is<br>that<br>(1) no side effects can be caused by the subatomic action, that is, no<br>
writes happen which could change future reads.<br>(2) the result of the computation is ignored -except- for whether it<br>retries or returns, that is, it can&#39;t affect the control flow of the<br>rest of the transaction.<br>
<br>So, if have a transaction T that is waiting inside &quot;retry&quot; for a<br>variable that it read to change, and a variable that is only accessed<br>in a &quot;subatomic&quot; part of T is changed, we can try running the<br>
subatomic computation first.&nbsp;&nbsp;Here are the four cases:<br><br>1) The subatomic computation succeeded before and still succeeded.<br>Then we know the end result of the computation is unaffected, and will<br>still retry.&nbsp;&nbsp;No need to do anything.<br>
2) The subatomic computation succeeded before and now fails (calls<br>&#39;retry&#39; or retryRO&#39;).&nbsp;&nbsp;Then we know that the computation will now fail<br>at this earlier point.&nbsp;&nbsp;Mark the change to &quot;fail&quot; in the transaction<br>
log and leave the computation in the &quot;waiting for retry&quot; state.<br>3) The subatomic computation failed before and still fails.&nbsp;&nbsp;See (1)<br>4) The subatomic computation failed before and now succeeds.&nbsp;&nbsp;The<br>result of the entire computation can change, we should now re-run the<br>
entire computation.<br><br>-- ryan<br></blockquote></div><br>