Proposal: Add System.FilePath to base

Neil Mitchell ndmitchell at
Wed Nov 22 12:25:05 EST 2006


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

Indeed, it used to be something else, I'll fix that.

> > addExtension :: FilePath -> String -> FilePath
> > 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?

No, on Windows \\drive (\\\\ because its escaped Haskell) is a server
share name, not a file name. This library understands that you can't
add an extension to a drive, since that doesn't make sense.

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

My guess is "/.x" - although I'm not at a computer with Haskell at the
moment. It's a valid question so I'll update the documentation to
include this corner case as a test.

> Speaking generally, for many functions I miss a precise description of the
> semantics that includes all the corner cases.

The idea was to provide enough properties for corner cases that you
can figure it out, precisely, from just the properties. If there are
any other cases you feel unclear on I'll definately add them as tests.

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

Words are wolly, properties are quickchecked and precise, but I can
add some overriding principles and design notes to clarify things in
peoples minds.

> takeBaseName :: FilePath -> String  Source
>  Get the base name, without an extension or path.
>  takeBaseName "file/test.txt" == "test"
>  takeBaseName "dave.ext" == "dave"
| What is (takeBaseName "dir.ext/")? "dir"? Or ""? A general principle that
| would clarify this could be "An extension of a file path is always a suffix
| of the file path. It never contains a path (directory) separator."

That can indeed be expressed, I'll add some properties to cover this
case and others later.

I will update the documentation later today or tomorrow, and let you
know when I have done so.



More information about the Libraries mailing list