filepath

[Ian Lynagh]

On Wed, Dec 12, 2007 at 09:23:27AM +0000, Simon Marlow wrote:
> Ian Lynagh wrote:
> >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 reason *not* to make "." </> p == p is that in some contexts (e.g. 
> rawSystem) "foo" is not the same as "./foo".

In that case surely we'd need to change

    Prelude System.FilePath> normalise "./foo"
    "foo"

too, and the property above would still hold?

> You could argue that rawSystem is therefore not taking a proper FilePath as 
> an argument, it is taking something else, and we should be more explicit 
> about it,
> 
>  data ExecutableSpec = FindOnPath String | Relative FilePath
> 
> this certainly has some merit.
>
> However, if we don't change the API of rawSystem, then having "." </> p == 
> p would make it somewhat harder to construct the argument to rawSystem, you 
> would have to do it manually: "." ++ pathSeparator : "foo".
> 
> I guess that seems reasonable, given that rawSystem is really the exception.

OK, I think we are in agreement then.


Thanks
Ian