[Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell

[Johan Holmquist]

I just want to pop up and say that on modern computers...

Seriously though, wouldn't it be reasonable if putStr flushed? Often in
Haskell  one constructs a long string to be output and there could still be
buffering.
On Feb 4, 2015 4:36 AM, "Brandon Allbery" <allbery.b at gmail.com> wrote:

> 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
> subsystems.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150204/41b2db64/attachment.html>