Simon Marlow wrote:
Doing a reasonable job on System.FilePath, even if it isn't perfect, will help prevent lots of applications from falling into common traps, and help make more code portable.
But the library code itself falls into the same traps! It's a great example of the kind of code we should be trying to replace! In many ways a library which violates its own interface specification is worse than no library at all. Inasmuch as the FilePath library doesn't violate its interface it's because the interface isn't well enough specified to prove a violation. The examples in the documentation are the obvious cases that Joe Programmer's hacked-up code is going to handle anyway. The non-obvious cases may break Joe's code; they definitely break the library. My concern here is that someone will actually use the library once it ships, with the following consequences: 1. Programs using the library will have predictable (exploitable) bugs in pathname handling. 2. It will never be possible to change the current weird behavior, because it might break legacy code. The System.FilePath library will have to remain in GHC forever in its current form, enticing programmers with its promise of easy pathname handling and then cruelly breaking its contract. If no one uses it in production code then we can fix it at our leisure, and having it out there with "experimental" status isn't necessarily a bad thing in that case. It just feels like we're playing a dangerous game. With respect to the old message you linked to: having an ADT for paths would not break any code, if what that means is that we provide parsePath :: String -> Maybe Path showPath :: Path -> Maybe String and various (new) functions operating on the Path type. I'd be much happier even if we just kept (roughly) the existing interface, but implemented it using a private ADT internally. Right now each function has its own integrated parser, with slight differences in e.g. drive letter handling, and there are probably more bugs I didn't notice. -- Ben