On Thu, Aug 24, 2006 at 12:38:34PM -0700, John Meacham wrote: > On Thu, Aug 24, 2006 at 02:26:42PM +0100, Frederik Eaton wrote: > > Because of what you said above, it's not perfect. But it's better than > > the default. Look, if someone is writing something to standard error, > > it's probably because they want to accomplish something, such as > > printing a message that the user can read, rather than just printing > > garbage. You need a pretty compelling reason to want to make such a > > basic part of the API useless, and so far you haven't given one. > > Well, the idea behind stderr being unbuffered, is that stderr is for > reporting erronious conditions, if your program is going wrong, you want > as much information as you can out of it. printing "['a','b','c'," is a > whole lot more informative than just printing nothing, as it shows > exactly which list member is infinitely looping. The other reason is > principle of least surprise. stderr is pretty much always unbuffered by > default (as in, ANSI c specifies it, and most (all?) languages with a > concept of buffering follow suit) . I would find it quite odd for > haskell to be different than unix norms. > > for multithreaded logging, I have always used a mutex to protect the > logging device.
I can see what you're saying. Personally, I don't tend to write things involving lots of computation to stderr. I've actually never encountered an infinite loop while writing to stderr - but I have encountered the problem with multiple threads. And I think it's just kind of embarrassing to have "outputting garbage" be the default behavior. I think the problem should at the very least be mentioned in the documentation. You talk about the "principle of least surprise", but that's quite surprising behavior... Also, I don't see why there couldn't be some compromise - like, if a line buffer is non-empty for more than some small amount of time, then flush it automatically. That would solve both problems. Frederik -- http://ofb.net/~frederik/ _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
