Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
Hi Neil,
On 7/17/06, Neil Mitchell
Hi Brian,
You sent this email just to me, and not to the list. If you indended to send to the list then feel free to forward my bits on to the list.
I know that FilePath is defined by Haskell '98 as a String and so it cannot be changed. So, perhaps a new type or class should be created for this library (hereafter "GoodPath," although I am not suggesting that is the best name). The problem is people will have to marshal their data into this GoodPath, and marshal it out again. When people can shortcut that marshalling, as the current readFile/writeFile definitions ensure they can, they will. At that point you loose all safety because people will abuse it.
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. 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"). 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. - Brian
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
participants (2)
-
Brian Smith -
Neil Mitchell