On 30 May 2007, at 2:45 am, GHC(simonmar) wrote:
I'm aware that everyone else does this, and I'm aware that GHC is
different.
GHC provides many important, useful, even exciting extensions over
other Haskell implementations. I don't mind a wee bit of
incompatibility
when it buys me something. On the other hand, I do like to be told
about
my mistakes quickly. So I like to use other Haskell processors as
"checkout compilers" and then compile with GHC at the end for
performance. So any incompatibility in core Report/Library features is
a pain in the neck.
But in this case, it's not just a matter of incompatibility with other
Haskell systems. GHC actually breaks an example in the Report.
Let me repeat that: the Haskell 98 report contains on page 98 in
section 7.2 an example showing precisely the kind of prompt/read
that DOES work in other Haskell implementations but not in GHC.
Here's the example:
main = do
putStr "Input file: "
ifile <- getLine
putStr "Output file: "
ofile <- getLine
s <- readFile ifile
writeFile ofile (filter isAscii s)
putStr "Filtering succssful\n"
Do you see a call to hFlush there? I don't see any call to hFlush.
Do you see a call to putStrLn there, or any other way of terminating
the line before calling getLine? I don't see any call to putStrLn
there, or any other way of terminating the line before calling getLine.
This is exactly the kind of code that my students and I expected to
work, because the Report *showed* us that it should work.
Nevertheless, I did it this way on purpose. Why? Because I think
it's an
ugly special case, and I didn't want to add it to the code.
Ideological purity is all very well, but it should not get in the way
of making the examples in the Report work. Of course, if a
specification
is unimplementable (like the ANSI Smalltalk's requirement that
timestamps
should use UTC even for future dates, where the number of accumulated
leap seconds is simply unknowable) then it shouldn't be implemented.
The
relevance of all those other Haskell (and other language)
implementations
is to demonstrate that this Report requirement is implementable.
If you expect
stdin/stdout to have this odd interactive behaviour, you might start
expecting it to happen on sockets too, and it won't. The
behaviour of
buffering in GHC is simple and works the same on stdin/stdout as
it does
on all other Handles. There's nothing in the Haskell 98 spec that
requires us to have magic flushing of stdout.
This turns out not to be true, as shown above. The example in section
7.2 DOES require stdout autoflushing.
Myself, I would not make this a special case. When I did the I/O
redesign for Quintus, this was one of the things I looked at, and
I said then and say now that whenever two language-level streams are
connected to the same device reading from any of the read streams
should auto-flush all of the write streams. (Amongst other things,
it is in general impossible for user code to do this, because the
user code in question doesn't *have* all of those streams, only the
ones it was passed.)
However, you don't have to do the general thing, just make the
example in the Report work.
I guess I wouldn't object if someone were to
submit a patch to implement this special case, as long as it
didn't affect
performance.
Since it is something that is done not on every character,
but only when an input stream's buffer is refilled, the performance
cost should be extremely small, even for the general case, which I
am not requesting.
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
