Abstract FilePath Proposal

Neil Mitchell ndmitchell at gmail.com
Sun Jun 28 21:09:41 UTC 2015


When talking about "filepath" specifically as something you prod at a
specific file system, you can think about normalisation, provided you
have a specific drive in mind. However, if you're going to do that, on
Linux it's almost better to use an inode number. I have two specific
problems with normalisation:

* You might hope for the property that after normalisation equality of
file locations is equality of FilePath values. That's not true. On
Linux you have symlinks. On Windows you have case sensitivity, which
is a property of the filesystem, not the OS. You might be able to
assume a == b ==> same a b, but you can never assume a /= b ==> not
(same a b), so normalisation doesn't really change the guarantee.

* I believe some Emacs user once told me that a//b is not the same as
a/b in some circumstances. On Windows, there are lots of programs that
require / or \. Some programs require ./foo and some require foo. The
exact path you pass to some programs gets baked into their output,
which is visible in the final release. While paths might be equal for
the purpose of asking a file system to get some bytes back, they are
often different for the other things people want to do with them, like
pass them to other programs that use the paths.



On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <m at tweag.io> wrote:
> On 28 June 2015 at 16:34, Sven Panne <svenpanne at gmail.com> wrote:
>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m at tweag.io>:
>>>
>>> why does the proposal *not* include normalization? [...]
>>
>>
>> I think this is intentional, because otherwise we are in the IO monad for
>> basically all operations. What's the normalized representation of
>> "foo/bar/../baz"?
>
> Notice that the kind of normalization I'm talking about, specified in
> the link I provided, does not include this kind of normalization.
> Because it requires the IO monad to perform correctly, and only on
> real paths.
>
> Here is the link again:
>
> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>
> Full canonicalization of paths, stripping out redundant ".." and
> whatnot, should certainly be done in a separate function, in IO.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


More information about the ghc-devs mailing list