putStr is not evaluated in the correct order
Hello, i've got a newbie question to ask. I'd like to ask for user input in the same line as the prompt. I found this example on the web main = do putStr "Who are you? " name <- getLine putStrLn ("Hello, " ++ name) This works find in ghci, but the compiled code (ghc 6.4.2) executes getLine first before executing putStr. Instead of: Who are you? myself Hello, myself I got: myself Who are you? Hello, myself I'm new with haskell, so I can't be too sure about this, but it seems from putStr implementation in Prelude, putStr should be executed first. Why are they different? And if they are suppose to be different, then how to put prompt and input on the same line for the compiled code? Thank you in advance -andre
Hello, GHCi and the compiled program do not buffer the output in quite the same way. In the compile program, stdout is line buffered, so it will not output anything until it gets a '\n'. You can force the output using 'hFlush stdout':
import System.IO main = do putStr "Who are you? " hFlush stdout name <- getLine putStrLn ("Hello, " ++ name)
You could also change stdout to be unbuffered -- but using flush is probably the prefered method:
main = do hSetBuffering stdout NoBuffering putStr "Who are you? " name <- getLine putStrLn ("Hello, " ++ name)
Either solution should make the GHCi and compiled version behave the same. The behaviour of the compiled version is consistent with most other languages under Unix. The behaviour under GHCi could be considered buggy -- it has certainly confused many people. On the other hand, I think the GHCi behaviour is also somewhat deliberate. j.
On Sat, Sep 02, 2006 at 05:11:33PM -0700, Jeremy Shaw wrote:
GHCi and the compiled program do not buffer the output in quite the same way.
This comes up so often that perhaps GHCi should advertise those differences. For example, the starting message could say something like this: ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.?, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. For a list of differences between GHCi-interpreted and GHC-compiled programs, type :differences Loading package base-1.0 ... linking ... done. Best regards Tomasz
Tomasz Zielonka wrote:
On Sat, Sep 02, 2006 at 05:11:33PM -0700, Jeremy Shaw wrote:
GHCi and the compiled program do not buffer the output in quite the same way.
This comes up so often that perhaps GHCi should advertise those differences. For example, the starting message could say something like this:
___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.?, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help.
For a list of differences between GHCi-interpreted and GHC-compiled programs, type :differences
Loading package base-1.0 ... linking ... done.
It is in the FAQ. The FAQ is currently a bit hard to navigate and could do with splitting up into separate pages, though. http://haskell.org/haskellwiki/GHC:FAQ#If_I_print_out_a_string_using_putStr..... We could consider adding a message along the lines you suggest... any other ideas? Cheers, Simon
Simon Marlow wrote:
We could consider adding a message along the lines you suggest... any other ideas?
I remember running into this. I wasn't confused by the expected behavior, it was the fact that ghci had different behavior than compiled programs and that the settings seem to be wrong at startup. I tracked down this bug at the time and forgot to report it. ghci starts with NoBuffering behavior, even though the mode appears to be LineBuffering. Setting it once fixes the problem. I've included a ghci session that demonstrates the bug by showing the change in behavior when pressing Control-D in response to each call to getLine. The results are identical for 6.4.1 and 6.6 rc1. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Prelude> :m +System.IO Prelude System.IO> hGetBuffering stdin >>= print LineBuffering Prelude System.IO> getLine >>= print ^D "\EOT" Prelude System.IO> hSetBuffering stdin NoBuffering >> hGetBuffering stdin >>= print NoBuffering Prelude System.IO> getLine >>= print ^D "\EOT" Prelude System.IO> hSetBuffering stdin LineBuffering >> hGetBuffering stdin >>= print LineBuffering Prelude System.IO> getLine >>= print *** Exception: <stdin>: hGetLine: end of file Prelude System.IO> ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.5.20060831, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m +System.IO Prelude System.IO> hGetBuffering stdin >>= print LineBuffering Prelude System.IO> getLine >>= print ^D "\EOT" Prelude System.IO> hSetBuffering stdin NoBuffering >> hGetBuffering stdin >>= print NoBuffering Prelude System.IO> getLine >>= print ^D "\EOT" Prelude System.IO> hSetBuffering stdin LineBuffering >> hGetBuffering stdin >>= print LineBuffering Prelude System.IO> getLine >>= print *** Exception: <stdin>: hGetLine: end of file Prelude System.IO>
On Mon, 04 Sep 2006 05:49:08 -0300, Simon Marlow <simonmarhaskell@gmail.com> wrote:
It is in the FAQ. The FAQ is currently a bit hard to navigate and could do with splitting up into separate pages, though.
http://haskell.org/haskellwiki/GHC:FAQ#If_I_print_out_a_string_using_putStr.....
We could consider adding a message along the lines you suggest... any other ideas?
C++ avoids this problem 'tieing' cin and cout. Why can't haskell do the same? Bruno
On 9/5/06, Bruno Martínez <br1@internet.com.uy> wrote:
C++ avoids this problem 'tieing' cin and cout. Why can't haskell do the same?
I was thinking the same thing. I'm imagining a situation where processes are communicating to each other using pipes, but cannot think of a concrete case. Do you know if C++ has any way to disable tying std::cin and std::cout? David
On Sat, 09 Sep 2006 23:34:55 -0300, David Sankel <camior@gmail.com> wrote:
On 9/5/06, Bruno Martínez <br1@internet.com.uy> wrote:
C++ avoids this problem 'tieing' cin and cout. Why can't haskell do the same?
I was thinking the same thing. I'm imagining a situation where processes are communicating to each other using pipes, but cannot think of a concrete case.
I don't see the problem. According to "The C++ Programming Language" cout is flushed only when cin encounters an underflow, so it doesn't seem costly either.
Do you know if C++ has any way to disable tying std::cin and std::cout?
Yes, cin.tie(NULL). Bruno Conectese mas rapido y ahorre hasta un 50% Tel. 0909.2030 => $0,15 IVA incluido el minuto ______________________________________________________ http://www.internet.com.uy - En Uruguay somos internet
participants (7)
-
Andreas S -
Bruno Martínez -
Clifford Beshers -
David Sankel -
Jeremy Shaw -
Simon Marlow -
Tomasz Zielonka