FPS again

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sun Jul 16 09:17:29 EDT 2006


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



More information about the Libraries mailing list