Endangered I/O operations

[Simon Marlow]

> > > If you handle std{in,out,err} connectedness in other ways,  I
> > > think you've
> > > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> > > Korn & Vo's SFIO, but it hasn't proved to be all that useful.
> >
> > I wasn't planning to handle connectedness at all.  Is it=20
> important, do
> > you think?  (I'm not against the feature, just trying to=20
> avoid feeping
> > creaturism...)
> >
>=20
> Yes, crucial I think - if stdout and stderr are connected to the same
> device,
> don't you want their output to be synchronised, e.g.,
>=20
> main =3D putStr "foo" >> hPutStr stderr " bar"
>=20
> should return "foo bar" on your TTY. Ditto for flushing=20
> stdout/stderr when
> peeking stdin.

You obtain the ordering properties by setting the handle to NoBuffering,
otherwise you get buffered input/output.  Wouldn't it be deviating from
the report to do extra flushing in the buffered case?  (this is
something of a technicality, actually we already do non-report flushing
in several cases and our line-buffered input isn't line-buffered at
all).

But I'm still not convinced we need to special case this.

Cheers,
	Simon