Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>FWIW, the package maintainer, Duncan Coutts, responded with some very helpful and enlightening remarks. I've asked for his permission to post them here, but in the interim here is a paraphrase.</p> <p>The basic point is that the documentation was once correct, but now probably is not. In particular, when one opens a file in windows, the operating system itself lets you open it in 'text' or 'binary' modes. The difference between <code>readFile</code> and <code>readBinaryFile</code> <em>used</em> to be that one would open the file in the OS's text mode and one in binary mode on Win32. (They would both do the same on POSIX.) Critically, if you opened a file in the OS's binary mode, there was <em>no way</em> you could read from the file without newline conversion: it happened <em>always</em>.</p> <p>When things were set up like this, the documentation referred to in the question was correct---<code>Data.ByteString.Lazy.Char8.readFile</code> would use <code>System.IO.readFile</code>; this would tell the OS to open the file 'Text', and newlines would be converted, even though <code>hGetBuf</code> was being used.</p> <p>Then, later, Haskell's <code>System.IO</code> was souped up to make its handling of newlines more flexible---specifically to allow versions of Haskell running on POSIX OSs, where there is no functionality to read files with newline mangling built into the OS, nonetheless to support reading files with Windows style newlines; or more accurately to support Python-style <a href="http://www.python.org/dev/peps/pep-0278/" rel="nofollow noreferrer">'universal' newline conversion</a> on both OSs. This meant that:</p> <ol> <li>The handling of newlines was brought into the Haskell libraries;</li> <li>Files are <em>always</em> opened in binary mode on Windows, whether you use <code>readFile</code> or <code>readBinaryFile</code>; and </li> <li>Instead, the choice between <code>readFile</code> and <code>readBinaryFile</code> would affect whether <code>System.IO</code>'s library code was set up to be in <code>nativeNewlineMode</code> or <code>noNewlineTranslation</code>. This would then cause the Haskell library conversion to do appropriate newline conversion for you. You could now also choose to ask for <code>universalNewlineMode</code>.</li> </ol> <p>This was at about the same time as Haskell got proper encoding support built in to <code>System.IO</code> (rather than assuming latin-1 on input and simply truncating output Chars to their first 8 bits). Overall, it was a Good Thing.</p> <p>But, critically, the new newline conversion, now built in to the libraries, <em>never affects what <code>hPutBuf</code> does</em>---presumably because the people building the new <code>System.IO</code> functionality thought that if one was reading the fine in a binary way, any newline conversion interposing itself was probably <em>not</em> What the Programmer Wanted, i.e. was a mistake. And indeed, it probably is in 99% of cases: but in this case, it causes the problem above :-)</p> <p>Duncan says that the docs will probably change to reflect this brave new world in future releases of the library. In the interim, <a href="https://stackoverflow.com/a/6860159/194894">there is a workaround listed in another answer to this question.</a> </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload