- 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.