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