Hi Neil,<br><br>On 7/17/06, <b class="gmail_sendername">Neil Mitchell</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Brian,<br><br>You sent this email just to me, and not to the list. If you indended<br>to send to the list then feel free to forward my bits on to the list.<br><br><br>> I know that FilePath is defined by Haskell '98 as a String and so it cannot
<br>> be changed. So, perhaps a new type or class should be created for this<br>> library (hereafter "GoodPath," although I am not suggesting that is the best<br>> name).<br>The problem is people will have to marshal their data into this
<br>GoodPath, and marshal it out again. When people can shortcut that<br>marshalling, as the current readFile/writeFile definitions ensure they<br>can, they will. At that point you loose all safety because people will<br>
abuse it.</blockquote><div><br>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.
<br></div><br>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<br>(canonicalPath "c:\hello there.txt ") would give "C:\Hello There.txt").<br><br>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.<br><br>- Brian<br></div>