> On 5 Nov 2019, at 07:51, Akim Demaille <a...@lrde.epita.fr> wrote: > >> Le 4 nov. 2019 à 21:16, Hans Åberg <haber...@telia.com> a écrit : >> >> >>> On 4 Nov 2019, at 18:12, Akim Demaille <a...@lrde.epita.fr> wrote: >>> >>>> Le 4 nov. 2019 à 17:03, Matthew Fernandez <matthew.fernan...@gmail.com> 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.
