Adding System.FilePath

[Wolfgang Thaller]

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