Re: [boost] [filesystem] Request for comments onproposedrelative()function

Subject: Re: [boost] [filesystem] Request for comments onproposedrelative()function
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2014-05-18 09:44:38

On Fri, May 16, 2014 at 6:51 PM, Peter Dimov <lists_at_[hidden]> wrote:

> Yakov Galka wrote:
>
>  Basically higher rank elements erase the lower rank ones, highest rank is
>> absolute. So here, rank(drive) > rank(root) > rank(regular), rank(x) = max
>> rank of elements of x. You add the requirement that relative() returns a
>> minimal-rank path, and I think you are ok with uniquiness on Windows and
>> Unix.
>>
>
> It's a bit more complicated than that on Windows, because these two:
>
> z1 = "/a"
> z2 = "c:a"
>
> have the same rank (or, to be precise, their ranks can't be ordered) -
> both are between relative and absolute. One is drive-relative,
> directory-absolute, other is drive-absolute, directory-relative.
>

This is not what I have defined. It is:

rank(z1) = max(rank(root), rank(regular)) = rank(root)
rank(z2) = max(rank(drive), rank(regular)) = rank(drive)

Is z2 absolute? Wrt. what definitions?

* "Definition 1" (x / "c:" = "c:" for all x), and either yours or mine
(equivalent) definitions of is_absolute: then z2 is absolute because x / z2
= z2 for all x. Then my claim that path of max-rank (here rank(drive)) is
absolute is true.

* "Definition 2", ("c:" / x / "c:" = "c:" / x ...): you cannot define ranks
for such concatenation. If you give ranks to elements you get a stronger
framework, which, in particular, is associative.

These "definitions" aren't proper definitions though. Abstract path
concatenation is associative by definition (in my OP), so the question is
how we define a valid str() function and action of elements on filesystem
nodes.

It *is* possible to define str() to achieve the effect intended in
"Definition 2". By example, think of str("c:" / "a" / "d:" / "b") =
"c:a/d:b". I.e. you serialize the whole per-drive current directory
state-delta as a prefix of the path. It would be associative. However, this
is an extension over Windows path syntax, so we definitely don't want to go
there.

Ironically, this is what boost.filesystem does (cats two valid paths to
give an invalid one: "c:/a" / "d:/b" = "c:/a/d:/b").

Alternative, non-equivalent definition of is_absolute:
------------------------------------------------------

Definition: is_absolute(x) iff system_complete(x) is equivalent to x.

Assuming that "c:" isn't absolute enough for us, this definition may make
more sense. Note that it is even more logical given that system_complete()
is the true absolute() on Windows. Yet another definition:

Definition: is_absolute(x) iff system_complete(x) is eval-equivalent to x.

Which raises the interesting question whether we want "c:/a/../b" to be
absolute.

-- 
Yakov