On 22/09/2009 16:43, Duncan Coutts wrote:
On Mon, 2009-09-21 at 12:00 +0100, Simon Marlow wrote:
The main change is that
splitFileName "foo" = (".", "foo")
and
takeDirectory "foo" = "."
and
"." x = x
So to re-iterate the point made in the ticket, the principle here is that the representation of the current directory is "." and not "". This lets us safely use results of System.FilePath functions as arguments to system and directory functions without having to check for "".
However the principle is not without exception, we also want to elide the explicit representation of the current directory when it is not needed.
If these are the principles then can we look at whether we apply them elsewhere in System.FilePath consistently?
What about:
joinPath [".", "foo"]
should it be "./foo" or "foo" ?
If "./foo" then it's not the same as, if the latter then we loose the property
Valid x => joinPath (splitPath x) == x
it would be some kind of limited normalisation.
So I'm happy with the first two changes, I'm less convinced about changing to elide "." on the left. Perhaps people who worry about leading "./" when the FilePath is displayed to the user should just use normalise. That's what they do now and we seem to get along ok.
So this subject was discussed between Ian and myself in the original thread, see e.g. http://www.haskell.org/pipermail/libraries/2007-December/008776.html The conclusion was that in the filesystem semantics "./foo" is equal to "foo", but the string passed to rawSystem (and execp()) is not a FilePath, it is something like Either FilePath String. However, there are some oddities with the current proposal. e.g. splitFileName "./foo" == ("./", "foo") "./" "foo" == "./foo" The current proposal just about hangs together because the tiny bit of normalisation that does exactly undoes the creation of "." in splitFileName, and there's no other way that splitFileName can generate ".". That's a terribly fragile property. If we "fixed" to do more normalisation, then we would no longer have the property that uncurry () (splitFileName x) == x (*1) I don't actually care about the details here as long as we have a story that is reasonably consistent. My main concern is that isValid x => isValid (takeDirectory x) the lack of which is the main problem with the current formulation, as you (Duncan) mentioned above. Perhaps we should drop the magic normalisation that does, and apply the normalise function to both sides of (*1). There would probably be a bunch more properties that would have to change too, I'm guessing that normalise would proliferate. Incedentally, I dislike the way that trailing slashes are treated in the current filepath implementation. A trailing slash is significant in POSIX: $ ls -l foo lrwxrwxrwx 1 simonmar GHC 15 2009-09-23 14:04 foo -> /does/not/exist $ ls foo foo@ $ ls foo/ ls: cannot access foo/: No such file or directory The path with the trailing slash dereferences a symbolic link, and may fail if the link points nowhere. I think trailing slashes should be dropped by splitFileName. Cheers, Simon