Binary IO

[Benjamin Franksen]

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