Proposal: Add System.FilePath to base

[Benjamin Franksen]

Neil Mitchell wrote:
> I guess most people saw this coming, but here is the proposal to add
> System.FilePath to base. The System.FilePath module is located at
> http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath

Some comments about the documentation:

> searchPathSeparator :: Char
> A list of possible file separators, between the $PATH variable

Should be: "The character that is used to separate the entries in the $PATH
environment variable."

> addExtension :: FilePath -> String -> FilePath
> Add an extension, even if there is already one there. E.g.
> addExtension "foo.txt" "bat" -> "foo.txt.bat". 
> addExtension "file.txt" "bib" == "file.txt.bib"
> addExtension "file." ".bib" == "file..bib"
> addExtension "file" ".bib" == "file.bib"
> Windows: addExtension "\\\\share" ".txt" == "\\\\share\\.txt"

I don't understand the last example. Is that because "\\\\xyz" where "xyz"
contains no pathSeparator can never be a file?

What, then, is the result of (addExtension "/" "x")? What, in general, is
the behavior in case the first argument ends with a path separator?

Speaking generally, for many functions I miss a precise description of the
semantics that includes all the corner cases. This would (IMHO) be even
more useful than the examples. It would also be nice to have principles
explained somewhere, e.g. "In order to be easily reversible, splitting
never discards separator characters. Instead these remain with either the
first element of the result pair (for directory-filename splits) or the
second element (for filename-extension splits)". I'm not sure if this
principle is really generally followed, but if it is, then this and similar
explanations would be very useful. It would also help to have guiding
principles for the usual corner cases, like (see above) what happens with
adjacent path and extension separators.

Ben