[Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell
allbery.b at gmail.com
Wed Feb 4 03:35:59 UTC 2015
On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu <madhub.bits at gmail.com> wrote:
> 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 ).
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.
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.)
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.
(*) 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
brandon s allbery kf8nh sine nomine associates
allbery.b at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe