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
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
[...]
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.
You're right, this was my main question. I read the paper "Tackling the Awkwar Squad: monadic input / output, concurrency, exceptions, and foreign-language calls in Haskell", Simon Peyton Jones, available at http://research.microsoft.com/users/simonpj There is an operational semantic given for the IO system, and I think this semantic ensures strict sequencing of IO actions. In this paper the echoTwice-example is given, and I was a little bit confused about the abnormal behavior of the program when I executed it. I didn't think at the buffering, but now it seem to be clear... Thanks for your comments ------------------- David Sabel JWGU Frankfurt
"Simon Marlow"
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.
...
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?)
The previous impl had facilities for controlling this - you could label handles as being connected (i.e., read() on one caused flushes on the other.) By default, stdin was connected to stdout and stderr. If that turned out to be troublesome, the connection could be broken (I could be mistaken, but I believe the implementation of hConnectTo didn't provide this; trivial to add.) My guess is that most of _your_ users wouldn't want to modify that default. As a data point, I cannot remember this ever being reported as a problem. If you don't think this is solving a problem, fine. I've had my say. --sigbjorn
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?)
AFAICS, the only "non arbitrary" policies would be:
a) never, and
b) whenever the equivalent ANSI C functions would flush; i.e. flush
all buffered output streams whenever a read from an input stream
cannot be satisfied from the buffer and is passed down to the OS. For
unbuffered input streams, this applies to all reads.
Either of these approaches will confuse some set of users. Anything
other than disabling buffering altogether will confuse users who are
completely unaware of buffering.
--
Glynn Clements
participants (5)
-
David Sabel -
Glynn Clements -
MR K P SCHUPKE -
Sigbjorn Finne -
Simon Marlow