#1355: Interactive I/O with ghc doesn't prompt until after reading
----------------------------------------------+-----------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Prelude | Version: 6.2
Severity: normal | Resolution: invalid
Keywords: interactive stdio late prompt | Difficulty: Unknown
Os: Multiple | Testcase:
Architecture: Multiple |
----------------------------------------------+-----------------------------
Comment (by Frederik):
This was sent by "ok <[EMAIL PROTECTED]>" to the glasgow-haskell-bugs
mailing list, but didn't show up in the bug report (and I agree with it):
> You're expecting unbuffered output,
WRONG! Not a bit of it. I am expecting C-like behaviour where
standard output is line buffered, BUT reading from stdin implies
an automatic flush of stdout.
>but GHC does line-buffering by default
> when outputting to a terminal.
This is not relevant. The behaviour I expect is provided by
EVERY other Haskell implementation I tried, and is also provided by
every Prolog system I tried (all of which buffer stdout), and by
every Scheme system I tried (again, no unbuffered output is involved
or needed), by the Common Lisp system I just tried (again using
buffered output). And you might care to try typing
(print "Prompt> "; TextIO.inputLine TextIO.stdIn);
at a Standard ML system, which again does exactly what I expect.
If ML, Scheme, Lisp, Prolog, and above all C (whose library GHC
presumably builds on) can all get this right, why is it hard for
Haskell to get it right? But wait, it ISN'T hard for Haskell to
get it right. ALL the other Haskell systems I tried DID get it
right, remember?
It's GHC that is the odd one out.
>If you want no buffering, you have to ask
> for it: `hSetBuffering stdout NoBuffering`,
No, I *don't* want no buffering. It's such a simple thing: just before
going to the operating system for more characters, you say "if this is
stdin and stdin is a terminal and stdout is a terminal, flush stdout."
By checking at startup
terminal = isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)
? STDIN_FILENO : -1;
then the test is a single comparison:
if (fd == terminal) fflush(stdout);
n = read(fd, buffer, sizeof buffer);
instead of just the call to read().
This is what C has given me since before C89. This is the behaviour I
get from every other Haskell system I have been able to try. The fact
that GHC does not do it really is a *BUG* in GHC.
>or else use explicit flushing:
> `hFlush stdout`.
Thank you for the workaround which I shall pass on to my students.
However, the fact that GHC does not do this automatically is a pain
in the next, an incompatibility with other Haskell implementations,
an incompatibility of expectation with the C stdio which Haskell IO
so sedulously emulates, and is something which is easier to fix than
to dismiss.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1355>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
