On Mon, Aug 4, 2014 at 12:25 AM, Donn Cave
To address J.K.'s (lest I misspell) probably ironic question seriously, why I certainly say Haskell should strive to be as compatible as possible with ANSI C, whatever Mr. Allbery may think. Gratuitous difference in functionality that's clearly based on C I/O would benefit no one.
I *don't* fully agree with this, just because ANSI C is partly in the business of ensuring that ancient programs still behave to some extent, and ancient programs often use buffered I/O in situations where it isn't ideal but was typically better than unbuffered on ancient PDP11s, or vice versa. :) (And often don't use line buffering, as --- if the program is old enough --- it may predate it.) That said, on many platforms pipes kinda give you a taste of that environment; as IPC goes, they're fairly slow, so buffered I/O is often a visibly faster option. (Which is why there are lighter but more complex or less documented / characterized IPC mechanisms around on various Unix-like systems.) And I do mean "visibly"; it's still, even on modern hardware, not *that* difficult to end up with programs where you can see visible pauses between emitted characters if you disable buffering completely, whereas even with line buffering the program both loses the pauses and takes less time to run. But in any case, my main grump here is that anything that makes it harder (or non-viably slower) to interface Haskell with other programs makes it harder to use Haskell in practice. Stringing together programs with pipes is still common in the unix world (despite the efforts of e.g. the Gnome devs...) and Haskell defaulting to unbuffered (or line buffered, in the case of short lines) I/O on pipes would be unfortunate. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net