[Haskell-cafe] File path programme

Ben Rudiak-Gould Benjamin.Rudiak-Gould at cl.cam.ac.uk
Tue Jan 25 14:12:16 EST 2005

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 

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

More information about the Haskell-Cafe mailing list