Re: Manual changes for api.prefix

[Akim Demaille]

Hi Arthur,

Please, keep it public.

Le 15 déc. 2013 à 16:18, "Arthur Schwarz" <address@hidden> a écrit :

> 
>> No it should not.  However, users of Bison 2.7 should not read the
>> documentation of Bison 3.0.
>> 
> %define api.prefix {prefix} [Directive]
> - Language(s): All
> - Purpose: Rename exported symbols. See Section 3.8 [Multiple Parsers in the
> Same Program], page 93.
> - Accepted Values: String
> - Default Value: yy
> - History: introduced in Bison 2.6
> 
> api.prefix was introduced in Bison 2.6. Are you saying that its
> implementation was changed in Bison 3.0 but not identified as changed? In
> Bison 2.7.1 api.prefix {prefix} generates and error.

The documentation of 2.7 is properly not using the braces.  Do not
mix versions of tools and documentations.  You are right that the
'history' snippet should document the change of syntax, which you
will find documented in the NEWS file.

Patches to improve this are most welcome.

> -------------------------------------------------
> 
>> Which is great for a language that supports namespaces.
>> What is exactly the problem you have?
> 
> The documentation indicates that yy prefixes are changed without any
> exceptions. In Bison 2.7.1 C++ yy prefixes are not changed, only the
> namespaces are changed. This is nowhere indicated in the text. Does Bison
> 3.0.2 modify this and keep the namespaces the same (yy) and change only the
> yy prefixes or does it change both.

I don't know that by heart, don't hesitate to check by yourself.
And then again, the core of the documentation, which is an introduction
to the generation of lalr(1) parsers, is in C.  I don't want to make
it multi-language, it wouldn't scale well.

However, the "reference" sections (with lists of specs, not the parts
that are really made to be read as a book) should definitely be
complete about all the languages.


> ---------------------------------------------------
> 
>> S/R conflict.  How should I read your 'and's?
> 
> Thanks. That gave me a good laugh.

Thanks :)  I did too actually.

> I think that the point was that the implementation mechanisms and underlying
> semantics are different in the three languages, and I see your point. Too
> many "and's", not enough sense.

I think that the confusion comes from the fact that you read
this chapter as an introduction to the "whole bison", which it
is not.  It aims at being a gentle introduction to Bison, with
C as support.  The remainder of the documentation aims at being
complete, and probably less "gentle".

I fear that trying to cover too many issues in this chapter (including
the difference bw the languages) would clutter and obfuscate it.

> ---------------------------------------------------
> 
>> I’m sorry, but I don’t fully understand what you mean.
>> The whole Chapter 3 is focused on C, not C++ and Java.
>> What would you suggest that we do?
> 
> Well, I suppose that Section 3.8 should consolidate all languages under one
> roof.

I'm not convinced.  Maybe a sister section, later, could address this,
but not there.

> You know, I am not unwilling to put my foot where my mouth is. That is,
> although making a critique is a shallow exercise in venting spleen,
> committing support is not, I am willing to support manual changes.

Wow…  You are way beyond my understanding of English.  And google
translate is not helping here (but thanks for this second good
laugh when I read its French translation.  Maybe a cascade of
translations through various languages, ending back in English,
will give you any idea

   You know, I am unwilling my foot where my mouth is.
   In other words, do a lot of criticism is an exercise
   in surface drainage in the spleen, support is not committed,
   I'm willing to support manual changes.

).