Re: Further C++ operators for position

[Akim Demaille]

> Le 4 nov. 2019 à 21:16, Hans Åberg <address@hidden> a écrit :
> 
> 
>> 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

(I meant "natural" here).

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

Yes, but that's not my point.  I mean: it is not important std::less "means" 
something natural, what matters is only that it's total and well-defined 
(unless, of course, you make this order visible to the user).  So I wouldn't 
mind defining std::less for position and locations.

But operator<= is expected to mean something natural (in addition to well 
defined and total).  So I would not define such an operator (except with a 
global offset/counter).


>> 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.
> 
> Here the files are stacked, and if the nested files are closed after being 
> read, the location pointers are dead.

W00t?  Typical parsers generate ASTs and typical ASTs are decorated with 
locations.