Re: Further C++ operators for position

[Akim Demaille]

Hi Matthew,

> Le 4 nov. 2019 à 17:03, Matthew Fernandez <address@hidden> a écrit :
> 
> 
>> On Nov 3, 2019, at 22:52, Akim Demaille <address@hidden> 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.