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 "incorrect" program. It's a bit in the gray zone I guess. You could even argue that it'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'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"><<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>></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<<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>> wrote:<br>
> On Fri, Aug 21, 2009 at 6:53 PM, David Menendez <<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>> wrote:<br>
>><br>
</div><div class="im">>> Some people dislike seq because it lets you force strictness<br>
>> in cases where pattern matching cannot (like function arguments), but<br>
>> hardly anyone objects to pattern matching.<br>
><br>
> Ah so it's subjective. Okay, it's sometimes hard for a newbie to find the<br>
> "truth" when several experts contradict eachother. Because often when people<br>
> claim something here, they have very good reasons for it, reasons that are<br>
> 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'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't have to worry<br>
about things like output happening too early because we haven't<br>
examined some input yet.<br>
<br>
This is also why some people object to getContents.<br>
<br>
<br>
For laughs, here's an example of IO code written using Haskell's old<br>
stream-based IO system, taken from "A History of Haskell":<br>
<br>
main :: Behaviour<br>
main ~(Success : ~((Str userInput) : ~(Success : ~(r4 : _))))<br>
= [ AppendChan stdout "enter filename\n",<br>
ReadChan stdin,<br>
AppendChan stdout name,<br>
ReadFile name,<br>
AppendChan stdout<br>
(case r4 of<br>
Str contents -> contents<br>
Failure ioerr -> "can’t open file")<br>
] where (name : _) = lines userInput<br>
<br>
<br>
It has a certain elegant purity, but I'm glad I don't have to use it.<br>
<div><div></div><div class="h5"><br>
--<br>
Dave Menendez <<a href="mailto:dave@zednenem.com">dave@zednenem.com</a>><br>
<<a href="http://www.eyrie.org/~zednenem/" target="_blank">http://www.eyrie.org/~zednenem/</a>><br>
</div></div></blockquote></div><br></div></div></div></div></div>