Duncan Coutts wrote:
On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
Exactly. I believe, a FilePath should be an algebraic datatype.
We've had this discussion before. The main problem is that all the current IO functions (readFile, etc) use the FilePath type, which is just a String.
So what's better? - use an ADT (correct and portable by construction), convert to String when calling the IO library - fumble with Strings, use an unholy mix of specialized and general functions, trip over a corner case
So a new path ADT is fine if at the same time we provide a new IO library.
We should just wrap the old API, filePathToString any parameters and liftIO the function while we're at it.
That's another portability headache - file name string encodings. Windows and OSX use encodings of Unicode. Unix uses strings of bytes.
Indeed. There are two ways out: - declare that Unix uses Unicode too, take the appropriate conversion from the locale - parameterize the FilePath ADT on the character type, you get (FilePath Word16) on Windows (which uses UCS-2, not UCS-4 and not UTF-16) and (FilePath Word8) on Unix; provide conversions from/to (FilePath String). I tend towards the second option. It at least doesn't make anything worse than it already is. It's also irrelevant, since pretending the issue doesn't exist works equally well with an ADT.
My point is it's not quite as simple as "just making an ADT".
Mine is that it is :) Moreover, a path already has internal structure. Those string manipulating functions either reconstruct the structure, then operate on that, then encode it back into a string or implement an approximation to that. The latter leads to surprises and making the former explicit can never hurt. Heck, NO library fumbles with strings, neither parsers nor pretty printers nor Network... why should a FilePath be different? Udo.