Message405288
Hi Arthur,
I agree that the line about "name ::= othername" could be more helpful.
I think an affirmative example would be better than a warning against depending on variable names, because the top of the page mentions that BNF is being used and IMHO the variable names are consistent with how BNF is typically used, so negative/warning language might be more confusing. I'm also not sure a note saying "read the documentation" in the documentation will help people read the documentation ;)
Maybe an example could be something like:
---------
In this and the following chapters, extended BNF notation will be used to describe syntax (but not tokenization/lexical analysis). Extended BNF uses syntax rules like the following:
a_expr ::= m_expr | a_expr "+" m_expr | a_expr "-" m_expr
This rule indicates that an a_expr ("a" is for addition, but subtraction has the same precedence) is one of the following:
* Just an m_expr (the "m" is for multiplication-like operations)
* A smaller a_expr, followed by a "+" sign, followed by an m_expr
* A smaller a_expr, followed by a "-" sign, followed by an m_expr
For concreteness, given that `x * y`, `x / y`, `a[i]` and `foo.bar` are instances of `m_expr`, the rule implies that `x * y`, `x / y + a[i]`, and (recursively) `foo.bar + x * y - a[i]` are all instances of `a_expr`.
---------------
Maybe there could be a link to a more-detailed BNF tutorial/reference. |
|
Date |
User |
Action |
Args |
2021-10-29 06:33:40 | Dennis Sweeney | set | recipients:
+ Dennis Sweeney, docs@python, Arthur-Milchior |
2021-10-29 06:33:40 | Dennis Sweeney | set | messageid: <1635489220.51.0.302741469188.issue45646@roundup.psfhosted.org> |
2021-10-29 06:33:40 | Dennis Sweeney | link | issue45646 messages |
2021-10-29 06:33:40 | Dennis Sweeney | create | |
|