[Haskell-cafe] File path programme

[Ben Rudiak-Gould]

Isaac Jones wrote:

 >You might be interested in the new FilePath module that's in the
 >works.  There's been a lot of work to make these functions portable.
 >
 >http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs

I didn't realize this was in CVS. IMHO this library is deeply broken, 
and should not be in GHC 6.4. We should be replacing ill-specified hacks 
with a carefully designed library, not an official collection of 
ill-specified hacks. It took me only a few minutes to find a bunch of 
cases which the CVS code mishandles, ranging from simple bugs, to cases 
where the existing behavior might be okay if documented, to cases where 
I'm not convinced there's any sensible behavior consistent with the 
function's type.

  (Win32)

  splitFileName "\\\\server\\share" ==> ("\\\\server","share")
    (should probably be ("\\\\server\\share",""))

  splitFileName "foo:xyz" ==> ("foo:.","xyz")
    (should be (".","foo:xyz") -- this refers to the named stream
     xyz of foo)

  joinPaths "c:\\" "\\foo" ==> "\\foo"
    (should be "c:\\foo". I realize that "cd c:\\" on Windows doesn't
     actually make "c:\\" the current directory, but ";" doesn't
     separate shell commands either.)

  (Posix)

  splitFileName "/foo" ==> ("/","foo"),
  splitFileName "/foo/" ==> ("/foo","")
    (arguably makes sense, but why isn't it documented?)

  splitFileName "/foo/bar" ==> ("/foo","bar")
  splitFileName "/foo//bar" ==> ("/foo/","bar")
    (definitely a bug)

  pathParents "/foo///bar" ==> ["/","/foo","/foo","/foo","/foo/bar"]

  pathParents "foo/../bar" ==> [".","foo/../bar"]
    (what if foo doesn't exist and we wanted to create it?)

Add to those the fundamental problems with splitFileExt which were 
already mentioned on this thread.

I don't even think the broad approach taken by the library interface is 
right. Manipulating pathnames with FilePath->FilePath functions is like 
refactoring a Haskell module with String->String functions. There should 
be parsing and serialization functions which convert between the 
external FilePath representation and an internal ADT, and the 
manipulation should happen on the ADT.

Please, let's not ship this with the hierarchical libraries. It's not 
ready for prime time.

-- Ben