On Sun, 2006-07-16 at 12:55 +0400, Bulat Ziganshin wrote:
So presumably the correct solution is to have the readFile, writeFile etc in the Data.ByteString module use openBinaryFile and the versions in Data.ByteString.Char8 use openFile. That way the versions that are interpreting strings as text will get the OS's line ending conversions.
i will vote against this because in Haskell I/O system there is already informal principle that functions which open files in text mode has plain names (openFile, readFile and so on), while functions which open files in binary mode has 'Binary' in its names (openBinaryFile, at least). your proposal will add another way to distinct between functions working with text and binary files - based on the module where they are defined.
True. That is exactly what the Data.ByteString / Data.ByteString.Char8 module split does however. It takes two interpretations of blocks of binary data. One interprets them just as sequences of bytes. The other interprets the data as a string type of which ASCII is a subset.
this will complicate the things without need. it will be much better to continue existing conventions and name such functions readBinaryFile and so on. but because such functions was not requested for the standard lib, i guess that they also not much required for the new one. so, i propose to move these text-file manipulating operations to the .Char8 modules and don't implement readBinaryFile/... at this moment
It's crucial to be able to read ordinary ByteStrings with a binary interpretation, otherwise we cannot parse binary protocols or files, or indeed even read non-ascii text files. I can see that there is an argument for calling them: Data.ByteString.readBinaryFile Data.ByteString.Char8.readFile Let's see what other people think. Duncan