Hi Simon,
- remove addFileName: it does the same thing as combine, or rather the difference is subtle and not mentioned in the docs. It's subsumed by combine, anyway.
The difference is subtle: System.FilePath> addFileName "test" "c:\\" "test\\c:\\" System.FilePath> combine "test" "c:\\" "c:\\" I'm coming around to the idea that addFileName is subtly different and entirely wrong, so yes, removing it seems fine.
- remove isDirectory. I think its presence is confusing, e.g forall x. isDirectory (takeDirectory x) == False! Also it's not really correct; "/bin/" means something subtly different to "/bin" on Unix systems. Similarly isFile, asFile, asDirectory could be removed, I think.
The reason I have them is because there are some circumstances where they are required in some programs. For example the behaviour of "cp" is different depending on whether the item is given as a file or a directory - hence these methods abstract away testing for that difference. I will think about this.
- Use the terminology "search path" consistently for anything to do with $PATH. i.e. fileSeparator => searchPathSeparator, isFileSeparator => isSearchPathSeparator, splitFiles => splitSearchPath
Ok, makes sense - I viewed it as a "collection of files", of which one instance is a search path. I guess in reality this will be the only "collection of files" so the name should reflect this.
also, move fileSeparator, isFileSeparator into the $PATH section in the docs (or change "basic functions" to "separator predicates").
Renaming basic functions to separator predicates is easy enough. I'd rather leave these predicates in a separate section so people are less inclined to use them - they are the building blocks that the higher level functionality is based on.
- remove splitPath: splitDirectories is enough. I'd rename it to splitPathComponents, though.
splitPath has the nice property that you can join it back together again with the right file separators: (\\ == \ since its escaped in a string) System.FilePath> joinPath $ splitPath "test/file\\more" "test/file\\more" System.FilePath> joinPath $ splitDirectories "test/file\\more" "test\\file\\more" This allows the developer to keep the FilePath more as the user specified. Maybe its not worth it though.
- shortPath => relativeToCurrentDirectory shortPathWith => makeRelativePath
I like them having the same prefix, it makes them more related in some way. makeRelative and makeRelativeToCurrentDirectory seem more natural to me. However, I'm not overly fussed. I've updated the way the versions of the FilePath library are organised, so once everyone's finished discussing this I'll try and get a 0.11 out in the next week that addresses these issues. Thanks Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe