Re: Further C++ operators for position

> Le 4 nov. 2019 à 21:16, Hans Åberg <[email protected]> a écrit :
> 
> 
>> On 4 Nov 2019, at 18:12, Akim Demaille <[email protected]> wrote:
>> 
>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez <[email protected]> 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.