On 15-Mar-07, at 7:18 PM, Neil Mitchell wrote:
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.
Surely both FilePath's and command line arguments are sufficiently string like that a reasonable interpretation of them is String? We don't want to provide an interface to Unix, we want to provide a proper abstraction over the underlying details.
Indeed, paths and command-line arguments are becoming very string- like on Unix systems, too. On Mac OS X, the locale for file names is pretty much hardcoded to UTF-8. Mac OS X's native file system stores file names in UTF-16, but the POSIX layer sees it as UTF-8. For the last several years, all Linux distros I have used myself had all their filenames stored in UTF-8. And even before that, there was usually a single filename encoding used for the entire system. I have also heard that Java, Qt and GTK all can't handle file names that are invalid in the current system-wide encoding. For all intents and purposes, filenames that don't match my system encoding on my linux box are unusable. I only need to be able to access them from 'mv' and 'rm', and if 'fsck' automatically renamed them for me, I'd be even happier. If people want to write Haskell replacements for these basic tools, they can be expected to use platform-specific lower-level functions imported from System.Posix.
It would be a shame if on my Windows box I had to jump through artificial hoops because Posix is a bit broken...
Repeat the above statement with s/Windows/Mac OS X/ and again with s/ Windows/Single-User Desktop Linux/. Cheers, Wolfgang