Re: Further C++ operators for position

> On 5 Nov 2019, at 07:51, Akim Demaille <[email protected]> wrote:
> 
>> 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.

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.