Proposal: System.FilePath: current directory should be ".", not ""

[Duncan Coutts]

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