<div class="gmail_quote">On Fri, May 15, 2009 at 4:02 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We ought to think about the interaction between text (and bytestring) and the new Unicode IO library. What does text have in the way of IO operations?<br>
</blockquote><div><br>Nothing. It has pure functions for transcoding to/from ByteString. Those functions aren't general enough, since they throw errors if an encoding problem is encountered. We'll need to provide alternatives that require an error handler as a parameter, so that you can do nothing, throw an error, or provide a substitution character instead.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've been wondering about what bytestring's hGetLine should do. Right now I have it doing decoding and then taking the low 8 bits, but that's not right. OTOH, looking for '\n' in a stream of bytes doesn't seem right. Maybe it should just be deprecated.<br>
</blockquote><div><br>It should be deprecated once there's something sensible to replace it with. Note that "something sensible" isn't necessarily straightforward; Unicode specifies 7 different code point sequences as newline equivalents (LF, CR, CR+LF, NEL, FF, PS, LS).<br>
</div></div>