On Tue, Dec 11, 2007 at 02:22:14PM +0000, Simon Marlow wrote:
Ian Lynagh wrote:
The two answers above together mean that the property
\x y -> let x' = normalise x y' = normalise y z = x' y' in z == normalise z'
doesn't hold (for x = ".", y = "foo"), but it is one I would expect to hold.
I think you have an extra ' on the last line of the code above.
Yes, thanks.
But anyway, why do you expect that to hold?
It just seems obvious to me that operators on a datatype would maintain normalisedness of that type. If it's not obvious to you then I'm not sure I can explain why; it's like explaining to someone why you find something beautiful. The only slightly similar thing I can think of is how the primitive operations of Ratio keep the components normalised, but that's slightly different as it's an abstract datatype, everything must be normalised on the way in, and normalisation prevents internal overflows.
Prelude System.FilePath> splitFileName "foo" ("","foo") I'd say this was expected. In a similar way, takeDirectory "foo" gives "", not "./".
I'd expect takeDirectory "foo" to be "." and dropFileName "foo" to be "./" too.
Right, me too.
But this is more of a pervasive design choice. It looks like System.FilePath consistently treats "" as a valid FilePath meaning "the current directory", and this would mean changing that policy.
As far as System.Directory is concerned, "" is not a valid FilePath (i.e. you can't say getDirectoryContents ""), and the current directory is denoted by ".". So it would seem sensible for System.FilePath to behave in the same way.
But then (splitFileName "foo") would have to give (".", "foo"), and
All agreed.
therefore
uncurry () (splitFileName x) /= x
which seems odd.
If it helps, I think that that seeming odd is similar to why I expect my property above to hold.
But perhaps the right property is
normalise (uncurry () (splitFileName x)) == normalise x
That should certainly hold, but I think \x -> let x' = normalise x in uncurry () (splitFileName x') == x' should too (and it does if "." p == p) Thanks Ian