[Haskell-cafe] File path programme

[robert dockins]

>  - Keep the existing System.IO API the same. openFile, createDirectory
> ... will take the file path as string.

The problem is that "string" means different things in haskell and in C.
A C "string" is really just a contiguous sequence of octets in memory. 
A haskell string has a particular interpretation, that of a list of 
unicode characters.  Depending on how strings come into and leave the 
haskell world, there may OR MAY NOT be a one-to-one mapping between C 
strings and haskell strings, if non-trivial character encodings are 
involved (they will be eventually).  Decoding may fail (no haskell 
representation for that string), or it might be that (deocde . encode) 
/= id, which is also bad (file name returned from a directory listing 
gives file not found error).  The sad truth is that FilePath = String is 
BROKEN.  FilePath = [Word8] would at least preserve filenames as they 
move across the boundaries of the haskell world, but then simple 
questions like "does this file have a .gz ending" become difficult 
(because they depend on the encoding).  We need something else.  Maybe 
ADTs aren't it, but String certainly isn't.  I don't think "mostly 
works, if you only use ASCII" is good enough for something as basic as 
file IO.

>  In most cases we do only simple manipulations on path 

Even simple manipulations break in the presence of encoding issues, or 
even just of unusual paths.  What is the extension of "\\.\TAPE0" ?  Its 
not "\TAPE0".  BTW this is a valid path on Windows 2000 upwards.  If you 
don't care about corner cases, then you have no worries.  It would be 
nice to have correct handling for all valid paths on each supported OS 
though.