Hi
I disagree. It would be trivial to create a new module that exported new definitions of file IO actions that operated on "GoodPath" instead of "FilePath," transparently delegating to the original readFile/writeFile/etc. until they could be removed in the future. This would also support the "SuperFilePath" idea you mentioned.
Yes it would, but because readFile etc. are in the prelude its not easy to not have them included. If someone was to write a System.SuperFilePath module and an IO.SuperFilePath module that would be great! I have considered it myself, but unfortunately don't have enough time, at the moment.
The advantage of moving to FilePath now is that its entirely non-breaking for anything, and once we have SuperFilePath, it makes it easier to migrate because (hopefully!) there will be less functions proding directly at FilePath's as strings.
Another thing I thought of would be a "canonicalPath" IO action (canonicalPath :: FilePath -> IO FilePath) that returns a FilePath that implements case-preserving-case-insensitive matching. For example, if there is a file named "Hello There.txt" in C:\, then (canonicalPath "c:\hello there.txt ") would give "C:\Hello There.txt").
Yes, thats a really good idea - and in fact when I wrote a FilePath module for Visual Basic (a long long time ago), I had such a function in it. I will make sure I add that tomorrow.
I think that the xxxDrive functions should only be exported from System.FilePath.Windows and no System.FilePath since it is unclear as to how they should be used effectively by cross-platform software.
I would say they shouldn't be used at all, but it is true that Posix.setDrive "c:" is a bit poorly defined. I will think this idea over, maybe the drive functions shouldn't be exported under either the general one or under the Posix, but it breaks a nice symetry that the library has... I have added a wiki page discussing System.FilePath, http://haskell.org/haskellwiki/FilePath, which is more a personal todo list, but if people want to summarise/propose things then feel free :) Thanks Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
