simonmar at microsoft.com
Fri Apr 22 08:19:51 EDT 2005
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
>> 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
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.
More information about the Libraries