Quoth Anthony Cowley
I think this is a consequence of line buffering rather than a bug. If you write your own increment function in Haskell, you get the same behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` call, you should get the behavior you wanted.
Though if you must do one or the other, I think hFlush makes as much sense. I think his perspective may be that the C stdio library appears to recognize that a TTY read is an occasion to flush stdout. If you already know better, there are ways to solve this problem - flush, change buffering, or use stderr instead of stdout. If you weren't expecting it, though, Haskell might by comparison seem a little retarded. Maybe it isn't a bug.
As things stand, it is quite a hassle to use a Haskell library of any complexity called from C.
And Haskell is slightly handicapped in this application, if it still doesn't support any good mechanism for top level mutable state (Cf. http://www.haskell.org/haskellwiki/Top_level_mutable_state ) I wonder if the fact that we recognize these problems but haven't been super-motivated to solve them, suggests that there hasn't really been that much call for stand alone Haskell libraries? (The proposal seems to say that C++ programmers could jump at this opportunity because they've been wanting to use Haskell but were afraid of the IO Monad?) Donn