<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu <span dir="ltr"><<a href="mailto:madhub.bits@gmail.com" target="_blank">madhub.bits@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Basically, in the following code, we print a line first and the read the line from stdin. This behavior works perfectly fine when using “runhaskell guess.hs”. But when i say “./guess”, i had to type in a number directly ( i.e. first prompt is skipped ).</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"></div></blockquote></div><br>runhaskell is presumably using unbuffered I/O for some reason, so outputting directly to the terminal. The compiled program follows standard Unix buffering conventions: line buffering on output to a terminal, so the putStr is sitting in a buffer waiting to see a newline output.</div><div class="gmail_extra"><br></div><div class="gmail_extra">C / C++ programs also do buffering, but there's a heinous hack which detects reads on stdin and flushes stdout beforehand. (Heinous because there is no guarantee that they are actually related --- but naïve programmers invariably do not learn about line buffering and expect all output to be unbuffered(*), and C standard library programmers eventually gave up and catered to them after years of trying to get them to pay attention. I have a nasty suspicion we're going to end up with a similar horrible hack in Haskell eventually.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">You can use hFlush from System.IO to flush the prompt out to the terminal, or disable output buffering with hSetBuffering in the same module.<br clear="all"><div><br></div><div>(*) At some point someone will pop up and say that on modern computers, buffering is obsolete because it's fast enough that horribly inefficient character-at-a-time I/O is good enough. Yet, I can *still* see visible hesitations when character-at-a-time I/O is used on a modern Intel core i5/i7. And your disk benchmarks will *tank* even with server-class disk subsystems.</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>