filepath should not return trailing path separators

[Bryan O'Sullivan]

Hi, Neil -

I'm writing some filesystem traversal code using filepath at the moment, 
and I am a bit disappointed to find it more error-prone and cumbersome 
than I had hoped.

The root of my problem is that splitFileName leaves a trailing path 
separator on the end of the first element of the tuple it returns:

   splitFileName "foo/bar" ==> ("foo/", "bar")

If I'm recursing up a file hierarchy towards the root directory (a 
common thing to do), this trailing path separator is a pain.  Either I 
forget that it's there and infinitely loop in the same directory over 
and over again, due to this behaviour:

   splitFileName "foo/" ==> ("foo/", "")

Or I have to remove it, with an unaesthetically named function:

   splitFileName (dropTrailingPathSeparator "foo/") ==> ("", "foo")

Having the trailing path separator omitted in the result of 
splitFileName and friends would both get rid of the possibility of the 
recursion bug (I'm surely not the only one who'll be bitten by it) and 
greatly reduce the frequency of the need to import and call 
dropTrailingPathSeparator.

I don't know how open the library is to such a change, now that GHC 
6.6.1 ships with filepath, but I consider the current behaviour to be 
quite unfortunate and undesirable, and very much worth fixing.

FWIW, Python's os.path.split has the trailing-"/"-elision behaviour I am 
advocating.

Thanks for your work on filepath.  I am glad to have it; I'd just be 
gladder if it wasn't so tricksy.

Regards,

	<b