sven.panne at aedion.de
Thu Mar 15 14:16:10 EDT 2007
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.
P.S.: The command line arguments are not really strings in *nix, either, so
the current API is wrong, too.
More information about the Libraries