On Thursday 15 March 2007 18:57, Bulat Ziganshin wrote:
Thursday, March 15, 2007, 8:10:18 PM, you wrote:
What is the general strategy for Haskell' regarding this topic: Is I/O out of the scope of Haskell' itself? If not, what are the plans/the strategy for transitioning to something more correct? To be honest: I don't see an easy way out without breaking lots of existing programs.
i see: just providing operations in libraries and allow one to import libraries he need. so, one can import FilePath 1.0 with String-based path representation or FilePath 2.0 with ByteString-based one
Alas, this is no solution at all. The point is: Currently there is no explicit conversion FilePath <-> String, although this is really needed. Users e.g. enter FilePaths somehow through a GUI, on the command line, in a configuration file etc., so you often start with a String. But this has to be converted somehow to a bunch of bytes for accessing the file, and this can't be handled without an API change (where does the encoding come from?). The same holds for reading e.g. a directory which should be presented to the user, only the other way round: You get a bunch of bytes and have to decode these for presentation purposes. Specifying a "default" encoding is not really the right way to go, because this leads to sloppy programs which only work under special circumstances and suddenly break on other platforms with different defaults. Cheers, S. P.S.: The command line arguments are not really strings in *nix, either, so the current API is wrong, too.