Abstract FilePath Proposal

wren romano winterkoninkje at gmail.com
Sun Jul 5 20:14:41 UTC 2015

On Sun, Jun 28, 2015 at 12:21 PM, Sven Panne <svenpanne at gmail.com> wrote:
> OK, then I misunderstood what you meant by "normalizing". But a question
> remains then: What is a use case for having equality modulo "normalise"? It
> throws together a few more paths which plain equality on strings would
> consider different, but it is still not semantic equality in the sense of
> "these 2 paths refer to the same dir/file". So unless there is a compelling
> use case (which I don't see), I don't see a point in always doing
> "normalise". Or do I miss something?

In my experience, the number one reason for (me to bother with)
normalizing paths is because I'm doing metaprogramming and want to
generate clean scripts. This includes both the IO and non-IO notions
of normalization. It's all about producing hygienic output, and it
would be nice to have all the OS-dependent things programmed away in a
library somewhere so I don't have to rewrite it.

IMO, normalization has nothing to do with equality. Then again, I
consider the notion of equality on file paths[1] to be as dubious as
the notion of equality on IEEE-754 floats.

[1] path *components* do have a well-formed notion of equality; it's
just that entire paths do not.

Live well,

More information about the Libraries mailing list