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

[Simon Marlow]

On 24/09/2009 18:20, Duncan Coutts wrote:

>> 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.
>
> So if we take the first bit of your proposal and not the second we have:
>
>          splitFileName "foo" == ("./", "foo")
>          "./"</>  "foo" == "./foo"
>
> and thus we do not have:
>
> uncurry (</>) (splitFileName x) == x
>
> because we end up with "foo" an "./foo"
>
> However I think that's fine. The splitFileName function is asking for
> the directory part of a relative/incomplete filepath and expecting it to
> be a real directory. Thus we are interpreting the original filepath as a
> complete filepath that is relative to ".". So given that by applying
> splitFileName we are taking that interpretation it's ok to get back
> "./foo", because we in that context we really were interpreting "foo" as
> "./foo".

I've amended the patch as suggested above, it turned out to be not too 
hard.  A few places were using splitFileName internally, and that broke 
some properties, e.g.

-- > Valid x => replaceFileName x (takeFileName x) == x
replaceFileName :: FilePath -> String -> FilePath
replaceFileName x y = dropFileName x </> y

the property doesn't hold any more because dropFileName "foo" == "./". 
So I worked around cases like this with an internal version of 
splitFileName with the old semantics.  This isn't a big problem - it 
just means we get to keep some of these nice simple equality properties, 
which are arguably wrong anyway, and fewer "./" prefixes will show up to 
surprise users.

Neil's comprehensive test suite still passes with the new patch.

Ticket, with new patch attached:

   http://hackage.haskell.org/trac/ghc/ticket/2034

The discussion deadline has long passed, so I propose we have another 2 
weeks (18 November).

Cheers,
	Simon