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. Some people have mentioned before that some systems (though not the native low level POSIX interfaces) do actually distinguish "./blah/blah" from "blah/blah". The distinction is whether a file is relative to the current directory or to some other unspecified root (eg a search path). Unix shells make this distinction for example when running "a.out" vs "./a.out". The latter is independent of the current $PATH, it really refers to the one in the current directory, not any such file on the $PATH. On a related note, when I have experimented with designing a typed version of FilePath, one of the things I wanted to distinguish in the types is exactly this thing about "relative to something specific" (eg relative to "/" or ".") vs "relative to something not yet specified". Another terminology might be "complete" and "incomplete". The OS file manipulation functions would only work on complete filepaths. Duncan