In addition, not all the target environments have the same capabilities. I/O may be from/to a file system, and so in systems with multiple file system types you can't even rely on a consistent set of capabilities at O/S granularity. This is a big problem for me as I'm implementing my database engine, which must force writes to disk for transactional semantics. The problem exists (as someone mentioned already) at the operating system level in many cases. Even if a consensus could be obtained about what the "Right Thing" is (not impossible at least in principle :) ) it is probably not possible to implement ANY policy consistently in all current target environments. On Monday 16 September 2002 21:41, Glynn Clements wrote:
Sigbjorn Finne wrote:
Look at this small programm:
module Main(main) where
main = echoTwice
echo = getChar >>= putChar
echoTwice = echo >> echo
while executing: the program reads first two chararcters and then it writes the characters, but in my opinion it would be right to read one character, then write one characater, then read, then write. What's the reason for it?
Buffering.
A deficiency of the current implementation of the IO system, I'd say. Reading from stdin ought to force a stdout (and stderr) buffer flush. The GHC IO libs used to do this.
The equivalent ANSI C I/O functions typically flush either all buffered output streams or all line-buffered output streams whenever a read operation is passed to the underlying system call (but not when it can be satisified from the input stream's buffer).
However, that won't make any noticeable difference unless the user explicitly puts the input stream into unbuffered mode. If the input stream is buffered, getChar doesn't (and shouldn't) return anything until Return (Enter, NewLine, ...) is pressed.
This is constant source of confusion for users & turning off buffering alltogether is a poor substitute for having the IO system do the Right Thing under the hood.
The "right" thing is a subjective notion. GHC already has some "magic" behaviour in this regard; i.e. using:
hSetBuffering stdin NoBuffering
automatically changes the terminal settings (e.g. clearing the ICANON flag) if stdin is associated with a terminal.
Even then, this won't "do the right thing" if the terminal itself (as opposed to the driver) is line-buffered; nothing will.
A user who wants unbuffered input will probably argue that "the right thing" is to make stdin unbuffered by default (along with clearing the ICANON flag). OTOH, a user who wants line-buffered input (i.e. the ability to use BackSpace/Ctrl-W/Ctrl-U) will probably disagree.
-- ----------------------------------- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849