On Friday 22 April 2005 14:19, you wrote:
On 22 April 2005 11:35, Benjamin Franksen wrote:
On Friday 22 April 2005 10:38, Simon Marlow wrote:
Lifting this constraint in GHC is a bit tricky because we currenly use the OS's text<->binary translation to do I/O (doesn't matter on Unix, right now).
So what? If the handle is in text mode, you won't get the exact bytes as they are in the file, when calling hGetWord8 (at least on some systems). But that is exactly what I would expect if the handle is in text mode. If I need the exact binary representation of a text file, I have to use binary, of course.
So if you open a file in text mode and read it with hGetWord8, what bytes do you expect to get, exactly? Perhaps each byte of the UCS-4 representation? Big endian or little endian order?
You could specify some meaning, but I don't think it would be a useful interface. And if you can't specify it precisely, it shouldn't be there.
Objection withdrawn. I haven't been thinking enough. A runtime error is probably better than an IO action that might produce random nonsense (or at least extremely unportable results) when used wrongly.
I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a line-buffered Handle,
I can't see a reason not to flush it. Could you explain why you think it should not? What have terminal settings to do with file handle modes??
Well, I have the notion that EOL is a text concept, so doesn't belong in binary I/O.
In principle I agree with this. It's only that we may want to layer character based functions on top of the binary ones. Although, from what Peter Simons writes, maybe I doesn't make much sense to do that...
On the other hand, it's easy enough to specify that writing the byte 0xa to a line-buffered binary handle has the effect of flushing it, just as we say that writing the character '\n' to a line-buffered text handle triggers a flush. So I'm happy to leave things as they are.
Maybe the best solution would be to make the behavior user configurable (per handle). Ben