IO-System

[Glynn Clements]

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 <glynn.clements@virgin.net>