Hi Arthur,
Le 8 juin 2022 à 19:07, slipbits <h...@slipbits.com> 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 <akim.demai...@gmail.com>
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:
