[Haskell-cafe] File path programme

[Marcin 'Qrczak' Kowalczyk]

Ben Rudiak-Gould <Benjamin.Rudiak-Gould at cl.cam.ac.uk> writes:

>  >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!

If problems are in the implementation but the interface is right, then
the module should be provided. It can be fixed later.

It's a bigger problem if the design is bad.

>     2. It will never be possible to change the current weird behavior,
> because it might break legacy code.

It will be possible if the old behavior is considered a bug. I doubt
that programs will make use of these bugs.

> With respect to the old message you linked to: having an ADT for paths
> would not break any code,

I don't see an advantage of using an ADT here.

> 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.

Well, they should be easy to fix as long as we precisely determine the
intended semantics.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/