> On 28 Sep 2018, at 13:39, Akim Demaille <[email protected]> wrote: > >> Le 28 sept. 2018 à 12:46, Hans Åberg <[email protected]> a écrit : >> >>> On 24 Sep 2018, at 22:36, Akim Demaille <[email protected]> wrote: >>> >>> In the case of stack.hh, I think we don’t care. In fact, I expect >>> people to ‘%define api.stack.file none’ to not generate this file. >>> But in the case of location.hh/position.hh, it might be important >>> to generate them in foo/ast while the parser is in foo/parse. >>> But then, what should the #include look like? Maybe we cannot >>> just invent it, and should also introduce api.stack.include to >>> specify it. >>> >>> Just thinking aloud. But I’d be happy to not be alone doing so :) >> >> Since you asked for it:-), it would be safest to have all these helper >> classes in the parser header, and with the same name prefix, or maybe even >> as subclasses. > > You mean inner classes.
Precisely, nested classes. > For stack, I agree. For locations/positions, I disagree. Their > interest escapes that of the sole parser. For instance, a good > AST should have locations. Yes, but how do you ensure that multiple occurrences do not clash? — With namespace, parse prefix, different install versions of Bison on the same system.
