Re: Further C++ operators for position

[Matthew Fernandez]

> On Nov 4, 2019, at 09:12, Akim Demaille <address@hidden> wrote:
> 
> 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.

For my constrained use case I did not require transitivity or symmetry, so it 
was not “frightening,” but I take your point.

> On Nov 4, 2019, at 12:16, Hans Åberg <address@hidden> wrote:
> 
> 
>> On 4 Nov 2019, at 18:12, Akim Demaille <address@hidden> wrote:
>> 
>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez <address@hidden> a écrit :
>>> 
>>> 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.  
> 
> The total order is expressed via std::less in containers such as std::map, 
> with undefined results if not fulfilling the specs for that.
> 
>> 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.

The language I am parsing has no #include mechanism, so I did not consider two 
positions with different filenames to be comparable. I don’t think you could 
immediately handle comparing positions with different filenames using the 
present data structures because, e.g., you could #include the same file twice.

> Here the files are stacked, and if the nested files are closed after being 
> read, the location pointers are dead.

Sorry, I don’t understand what you mean here Hans. The only pointers in the 
location class are the filename pointers within its begin and end positions, 
and these are not invalidated by closing input files.

>> 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.

Is it? What if you parsed two separate input sources? It makes no sense to 
order a position in one file with respect to a position in the other.