The question is, in this case when the user gets to see a bit too much of the output before he sees the input, if that really qualifies as an &quot;incorrect&quot; program. It&#39;s a bit in the gray zone I guess. You could even argue that it&#39;s a feature that input and output are not really synched, they are lazy, input is only read when evaluated; if you want to sync them, use a syncIO action ;-) no that&#39;s silly of course.†<div>
<br></div><div>Oh well, thanks for all the input, this was very informative for me hacker.</div><div><br></div><div><div><div><div><div><div class="gmail_quote">On Fri, Aug 21, 2009 at 10:20 PM, David Menendez <span dir="ltr">&lt;<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Fri, Aug 21, 2009 at 3:29 PM, Peter Verswyvelen&lt;<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>&gt; wrote:<br>

&gt; On Fri, Aug 21, 2009 at 6:53 PM, David Menendez &lt;<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>&gt; wrote:<br>
&gt;&gt;<br>
</div><div class="im">&gt;&gt; Some people dislike seq because it lets you force strictness<br>
&gt;&gt; in cases where pattern matching cannot (like function arguments), but<br>
&gt;&gt; hardly anyone objects to pattern matching.<br>
&gt;<br>
&gt; Ah so it&#39;s subjective. Okay, it&#39;s sometimes hard for a newbie to find the<br>
&gt; &quot;truth&quot; when several experts contradict eachother. Because often when people<br>
&gt; claim something here, they have very good reasons for it, reasons that are<br>
&gt; not obvious at all to your average newbie!<br>
<br>
</div>You can make a pretty good argument that programs which rely on<br>
strictness for correctness (as opposed to space/time issues) are<br>
risky, because it&#39;s easy to get things wrong by accident. Internally,<br>
the IO monad may rely on strictness to make sure things happen in the<br>
proper sequence, but all of that is hidden so we don&#39;t have to worry<br>
about things like output happening too early because we haven&#39;t<br>
examined some input yet.<br>
<br>
This is also why some people object to getContents.<br>
<br>
<br>
For laughs, here&#39;s an example of IO code written using Haskell&#39;s old<br>
stream-based IO system, taken from &quot;A History of Haskell&quot;:<br>
<br>
main :: Behaviour<br>
main ~(Success : ~((Str userInput) : ~(Success : ~(r4 : _))))<br>
 †= [ AppendChan stdout &quot;enter filename\n&quot;,<br>
 † †ReadChan stdin,<br>
 † †AppendChan stdout name,<br>
 † †ReadFile name,<br>
 † †AppendChan stdout<br>
 † †(case r4 of<br>
 † † †Str contents -&gt; contents<br>
 † † †Failure ioerr -&gt; &quot;canít open file&quot;)<br>
 † †] where (name : _) = lines userInput<br>
<br>
<br>
It has a certain elegant purity, but I&#39;m glad I don&#39;t have to use it.<br>
<div><div></div><div class="h5"><br>
--<br>
Dave Menendez &lt;<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>&gt;<br>
&lt;<a href="http://www.eyrie.org/~zednenem/" target="_blank">http://www.eyrie.org/~zednenem/</a>&gt;<br>
</div></div></blockquote></div><br></div></div></div></div></div>