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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
