IO-System

[Simon Marlow]

> The previous impl had facilities for controlling this - you=20
> could label handles
> as being connected (i.e., read() on one caused flushes on the=20
> other.) By
> default, stdin was connected to stdout and stderr. If that=20
> 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=20
> wouldn't want to
> modify that default. As a data point, I cannot remember this=20
> ever being reported as a problem.

Yes, I'm aware of hConnectTo.  It was a conscious decision not to
re-implement it in the new IO library.

There are really two separate issues:

  - Should we provide hConnectTo?  I can only think of
    one reason why not: it adds a small but non-zero
    overhead to lots of I/O operations.

  - Should stdin and stdout/stderr be connected by default?

Defaulting to connecting stdin and stdout is not always the right thing:
consider the case when the input and output are connected to different
pipes.  This is a dynamic property, so the program itself would have to
include code to check whether stdin and stdout are connected to the same
terminal and disable the hConnectTo if not.  Doing the right thing in
general is hard - suppose the program opens /dev/stdin itself and starts
to read from it, should this cause a flush of stdout?

You're probably right that we get more bug reports the way it is just
now, but it has the advantage of being simple and consistent.

Cheers,
	Simon