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.
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. 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. Cheers, Simon