Re: Further C++ operators for position

[Hans Åberg]

> On 5 Nov 2019, at 07:51, Akim Demaille <address@hidden> wrote:
> 
>> 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.

The point of implementing it would in use of containers like std::map, which 
will assume that std::less can be to define a total order.

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

It is only in C++ they are expected to relate to a total order, common use in 
partially ordered sets [1]. In fact, I defined a type “order” with values 
unordered, less, equal, greater, and it can be used to define a partial order. 

1. https://en.wikipedia.org/wiki/Partially_ordered_set


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

Only that when open an included file, one may use yyin = new 
std::ifstream(str), where all data, buffers and locations are stacked. Then 
after the file has been read, it is closed and the yyin pointer is deallocated.