Re: RFC: c++: provide control over the stack.hh file name

[Hans Åberg]

> On 28 Sep 2018, at 13:39, Akim Demaille <address@hidden> wrote:
> 
>> Le 28 sept. 2018 à 12:46, Hans Åberg <address@hidden> a écrit :
>> 
>>> On 24 Sep 2018, at 22:36, Akim Demaille <address@hidden> 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.