I agree, I certainly don't want inefficency introduced by unecessary flushes, and I would expect to control where the flushes happen. I think the query originally assumed a sequencing ambiguity in the IO monad... but in my experiance (all be it limited) the IO monad is there to ensure strict sequencing. To get the "correct" results both buffers have to be changed... module Main(main) where import IO main = do hSetBuffering stding NoBuffering hSetBuffering stdout NoBuffering echoTwice echo = getChar >>= putChar echoTwice = echo >> echo -- Or: using explicit flushing module Main(main) where import IO main = do hSetBuffering stdin NoBuffering echoTwice echo = getChar >>= putChar >> hFlush stdout echoTwice = echo >> echo Regards, Keean Schupke. Simon Marlow wrote:
I'd settle for that kind of indiscriminate flushing -- as is, trivial I/O examples such as
main = do putStr "What is your name? " ls <- getLine putStrLn ("Hello " ++ ls ++ "!")
fail to behave as expected.
That depends on what you expect... :-) The Haskell report says nothing about triggering a flush on stdout when reading from stdin.
I disagree that introducing this ad-hoc flush would be the right thing. A workaround for a common misconception, yes; but not the right thing in general. IMHO, it's better that programmers learn about buffering early because they'll get bitten by it later on anyhow.
Suppose we were to implement this, when exactly should it be enabled? All the time? When stdin is a terminal? When stdin and stdout are both connected to the same terminal? For every output handle connected to the same terminal as stdin? Should it happen for a socket too? (if not, won't that be confusing for users?)
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users