Re: Further C++ operators for position

Hi Matthew,

> Le 4 nov. 2019 à 17:03, Matthew Fernandez <[email protected]> a écrit :
> 
> 
>> On Nov 3, 2019, at 22:52, Akim Demaille <[email protected]> wrote:
>> 
>> Hi Matthew,
>> 
>> The semantics for line and columns are quite clear, so comparing Positions in the same file is quite well defined.
>> 
>> But what should you do when the files are different?  (And Locations are intervals, so there's no way to compare them totally in a natural order.)
>> 
>> What we can do, though, is offer implementations for std::less, that would blindly apply the lexicographic order in both cases.
>> 
>> But the case of file names remains troublesome: should we compare the pointer addresses (super fast, but non deterministic) or the pointees (super slow, but deterministic)?
> 
> The implementation I had in mind had all operators returning false when the filenames differed.

So this is not transitive nor anti-symmetrical, that's not an order at all.  Besides, with this definition, a <= b is not equivalent to b >= a, that's frightening.

> However maybe this is insufficient for defining a partial order? Some internet reading suggests these operators cannot be used to define a partial order and things like std::sort will malfunction.

It will certainly not work properly.


> I was not suggesting implementing any new operators for Locations, which I agree are orderable this way.
> 
> The std::less implementation you suggest is to also lexicographically compare the filenames themselves? I’m not sure this makes sense, because source positions from two different files aren’t really orderable at all.

The point of defining std::less is to have an easy means to insert positions in a sorted container, say std::map.  Now, the order in itself is well defined, but my not reflect the order the user would like to see.

To be clear: I don't have a problem with std::less which I see as an implementation detail, but operators such as <= and the like are different: they express a total order that we can't implement easily.  In addition, think of C where you also have main.c that #include "foo.h" somewhere, which results in main.c:1 (i.e., line 1) < foo.h:1 < ... < foo.h:42 < ... < main.c:3.

If we want a total order here, it's actually easy: positions should have a counter somewhere which is the *total* "offset" since the first byte of the first file.  Or something like that.

But we don't have it.