Re: Questions on 3.4.6 Actions

Hi Akim;

You seem to be the go-to person for Harsh and Unremitting Criticism; 
sorry. When you get tired of it all just say "I'm tired of it all, no 
more" and that'll be the end of it.

What is being said is that the User's Manual is incomplete in that it 
doesn't give a full description of the syntax. It selectively chooses 
what syntax to describe and ignores the rest. This is a request to 
expand the syntax descriptions to include the entire Bison specific 
syntax. I think I sent you a partial document to illustrate what I mean.

I think that the user should be made aware of what syntax is legitimate. 
For example, is "%token" a keyword or is "%" a delimiter and "token" a 
keyword. If "%" is a delimiter does that mean that between the "%" and 
the "token" there can be zero or more blanks. Must a Bison item be fully 
contained on a single line, or can it be on multiple lines. What is the 
alphabet. Where are blanks allowed. What is a delimiter, and so on.

I can volunteer my time to provide text (putting words where my mouth is 
- a sick, sad, pun). I'm not asking for something that I can't aid in 
producing.

thanks;
art

On 9/11/2022 10:30 PM, Akim Demaille wrote:
> Hi Arthur,
>
>> Le 8 juin 2022 à 19:07, slipbits <[email protected]> a écrit :
>>
>> In 3.4.6 Actions the format of a name, as in RULE[name], not mentioned nor is the scope of the name, nor any constraint. For purposes of this discussion we define EBNF tag as the RULE name.
> This is wrong.  First, it's not about rules, but about symbols (tokens and nonterminals) in rules.  Second, Bison is not about *E*BNF at all, and its notation for grammar is not BNF either.  They are called "named reference" in Bison, let's keep that name.  They are described in 3.6 (and 3.4.6 does point to 3.6).
>
> One should s/EBNF tag/reference name/g in your message.
>
>
>> Am I correct in assuming that:
>>
>> 1. A EBNF tag is composed of alphabetic, numeric characters and a dash
>>    ('-') and underscore, ('_').
> And period.  They follow the same pattern as symbol names, defined in 3.2.
>
>> 2. The format of a EBNF tagis ([a-zA-Z] | (-|_)+)([a-zA-Z]|'-'|'_'_)*.
>>    Embedded white space is not allowed.
> This is wrong.  Have a look at Bison's scangram.l.
>
> letter    [.abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_]
> id        {letter}({letter}|[-0-9])*
>
>> 3. EBNF tags are case sensitive. Name and name are different.
>> 4. EBNF tags can be used for terminals and non-terminals. For
>>      * expr : expr '+' expr
>>        expr[tag2] : exprtag2] '+'[tag3] expr[tag4] is legal
> FWIW, in the context of GNU projects, we avoid "legal" and prefer "valid".  Let's keep "legal" for justice.
>
>> 5. EBNF tags can only be used in a block statement (brace block).
>>    expr[name] : name + expr is not legal,
> I don't understand what you call a block statement in the context of Bison.
>
> expr[name] : name '+' expr
>
> is valid, independently of whether there's an action afterwards.
>
>> 6. Within a block statement, EBNF tag are referenced by '$'tag or
>>    '@'tag. That is, LHS[name] is referenced by $name or @name.
>>      * The '$' prefix refers to the terminal/non-terminal value
>>        (semantics).
>>      * The '@' prefix refers to the location of the
>>        terminal/non-terminal. (see 1.6 Location).
>> 7. The scope of a EBNF tag is the EBNF expression it is in, with the
>>    following conditions:
>>      * LHS[name] : RHS // is a scope
>>      * LHS[name] | RHS // is a scope
> "LHS[name] | RHS" is a syntax error, but I understand what you mean: yes when an lhs is provided with a reference name, then all its RHSes see that reference name.
>
>
>> 8. EBNF tags are unique within their scope.
>>      * LHS[name] : RHS[name] // is not legal
>>      * LHS : R1[name] R2[name] // is not legal
>> 9. EBNF tags declared in the EBNF statement do not  hide names within
>>    the scope of the block statement.For example:
>>          <type> name;    // in global scope
>>             o o o
>>         LHS[name] : RHS { $name = name;} is legal
> I don't see were the last "name" is defined (it will not be related to your "<type> name").  But for Bison, this is fine, yes.
>
>> 10. EBNF tags and terminal/non-terminal names can be the same. That is:
>>      * expr[expr] : expr '+' expr is legal
>> 11. The scope of the LHS EBNF tag is the entire expression. That is in
>>        LHS[name] : RHS1 {$name = }
>>                  | RHS2 {$name = }
>>    both refer the the LHS EBNF tag, name.
>> 12. yy and YY have special meanings within Bison and should not be used
>>    as EBNF tag prefixes. That is yyname and YYname are both legal but
>>    should not be used.
> Given that reference names are used only during parser generation and do not exist in the generated parsers, you don't have such constraints.
>
>> 13. "__" should not be used in C/C++ block statements. Both C and C++
>>    standards and compilers use these prefixes.
> Irrelevant to Bison.
>
>> 14. Where one blank is legal, many can be  used. The following is legal:
>>      * LHS  [  name  ] and
>>      * LHS[name  ] and
>>      * LHS[   name] and so on for the RHS.
>> 15. A "EBNF tag block" is defined as EBNF[name], where [name] is a "EBNF
>>    tag block". Only one name is allowed in  a EBNF tag block. That is
>>    LHS[name1 name2] is not legal
>> 16. The LHS EBNF tag has no value on rule reduction and must be assigned
>>    a value (lvalue). After assignment it can be used as an rvalue.
>>      * LHS[name] : ... { $name = value; ...}  // is legal
>>      * LHS[name]: ... { var = $name; .. }     // is not legal
>>      * LHS[name]: ... { $name = value; ... var = $name; ... )  // is legal
> Unrelated to named references (it's the same for $$, $1, etc.), and actually somewhat false.  Depending on the skeleton, $$ = $1 may have been run before executing the user action.  So "using" $$ before assigning to it may be valid.
>
>> 17. The RHS EBNF tag has a value on rule reduction.
> Unrelated.
>
>> 18. The EBNF tag for the LHS and RHS have a location on rule reduction.
> Unrelated.
>
>> 19. If the tagged terminal/non-terminal is a structure or class, then
>>    it's public members can be accessed by  using a '.',. if the EBNF
>>    tag is name, then for example,
>>      * if it has a value (semantic) as in
>>        struct {
>>            int x;
>>            int y;
>>        }
>>        then name.x refers to the x component of the structure.
> name.x denotes nothing at all for Bison.  $[name].x and $name.x do, and mean the same.  However $[name.x] uses 'name.x' has identifier.
>
>>      * if it is a location then name.first_column refers to a value in
>>        the location structure.
> You mean @mame.first_column.  And yes, it does.
>
>> Definition:
>>      LHS left hand size   LHS : RHS
>>      RHS right hand side   LHS : RHS
>>
>> Are these assumptions correct.
> Most statements are true, except the ones I answered to.  I will add the following patch to the documentation to clarify fuzzy bits.  Thanks for the report!
>
> Cheers!
>
> commit 15b97a0a6ab49a148cdfbe7d06d12b2624a33f97
> Author: Akim Demaille <[email protected]>
> Date:   Mon Sep 12 07:18:15 2022 +0200
>
>      doc: define the syntax of named references
>      
>      Reported by Arthur Schwarz.
>      https://lists.gnu.org/r/help-bison/2022-06/msg00007.html
>      
>      * doc/bison.texi (Named References): Define the syntax of named
>      references.
>
> diff --git a/doc/bison.texi b/doc/bison.texi
> index a4bc037e..b2eddcf8 100644
> --- a/doc/bison.texi
> +++ b/doc/bison.texi
> @@ -5024,7 +5024,12 @@ @node Named References
>   @end group
>   @end example
>   
> -@noindent
> +Like symbol names (@pxref{Symbols}), reference names can contain letters,
> +underscores, periods, and non-initial digits and dashes.  In bracketed
> +reference names, leading and trailing blanks and comments are ignored:
> +@samp{[ name ]} and @samp{[/* A */ name /* for references.  */]} are
> +equivalent to @samp{[name]}.
> +
>   In order to access a semantic value generated by a midrule action, an
>   explicit name may also be declared by putting a bracketed name after the
>   closing brace of the midrule action code:
>
>