&gt; main = do<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; --irrelevant&nbsp; x &lt;- newIVar<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; let y = last [1..]<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; print &quot;test&quot;&nbsp; --was irrelevant&nbsp; writeIVar x 3<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; print y<br><br>Exactly.&nbsp; The termination concern doesn&#39;t seem to have to do with readIVar.
<br><br><div class="gmail_quote">On Dec 4, 2007 11:56 AM, Isaac Dupree &lt;<a href="mailto:isaacdupree@charter.net">isaacdupree@charter.net</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>&gt;&gt; A pure readIVar would be just like lazy I/O, with similar drawbacks.<br>&gt;&gt; With readIVar, the effect that lets you observe the evaluation order<br>&gt;&gt; is writeIVar; with hGetContents it is hClose. &nbsp;Conclusion: it&#39;s
<br>&gt;&gt; probably no worse than lazy I/O.<br>&gt;<br>&gt; Actually, it&#39;s considerably better.<br><br></div>+: implementation may not evaluate something that may terminate/block,<br>anyway<br><br>IVar may change from blocking to non-blocking, unlike most pure
<br>expressions. &nbsp;This is only meaningful if trying to evaluate it would<br>prevent it from gaining a value. &nbsp;It can only have such an effect<br>(helping the IVar gain a value) if the same thread would do any IO (if<br>it wasn&#39;t for the unnecessary evaluation). &nbsp;IO is generally observable,
<br>so getting stuck on a normal non-terminating expression wouldn&#39;t be any<br>more acceptable than getting stuck on an IVar in that case.<br><br>... all assuming unsafeInterleaveIO doesn&#39;t exist, because it&#39;s unsafe,
<br>so the semantics are undefined of when it gets evaluated relative to<br>later normally-sequenced IO actions, if it will be eventually evaluated<br>for sure -- right? &nbsp;Nevertheless its intended use generally assumes that
<br>it will be evaluated as if its evaluation might not terminate, i.e. as<br>late as possible. &nbsp;If it is in fact (a finite amount of) non-blocking<br>IO, then evaluating it early will only have consequences on when the IO
<br>happens (and therefore its effect/result), not directly on the program&#39;s<br>non-termination or actions.<br><br>It gets more confusing the more I think about it!<br><br><br>to modify Simon&#39;s example, it looks to me like treating readIVar as
<br>potentially non-terminating, and writeIVar as potentially having<br>side-effects, is enough:<br><br>main = do<br> &nbsp; &nbsp; --irrelevant &nbsp;x &lt;- newIVar<br> &nbsp; &nbsp; let y = last [1..]<br> &nbsp; &nbsp; print &quot;test&quot; &nbsp;--was irrelevant &nbsp;writeIVar x 3
<br> &nbsp; &nbsp; print y<br><br>Isaac<br>_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">
http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br></blockquote></div><br>