On 1/23/08, <b class="gmail_sendername">Johan Tibell</b> <<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><div><br>[..] <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My proposal is for I/O functions to specify the encoding they use if<br>they accept or return Chars (and Strings). If they deal in terms of<br>bytes (e.g. socket functions) they should accept and return Word8s.<br>Optionally, text I/O functions could default to the system locale
<br>setting.</blockquote><div><br>Yes, this reflects my recent experience, Char is not a good representation for an 8-bit byte. This thread came out of my attempt to add a module to dataenc[1] that would make base64-string[2] obsolete. As you probably can guess I came to the conclusion that a function for data encoding with type 'String -> String' is plain wrong. :-)
<br><br>/M<br><br>[1]: <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.10.2">http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.10.2</a><br></div>[2]: <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/base64-string-0.1">
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/base64-string-0.1</a><br></div>