Oops - correction:

The grammar rule "additive-expression: multiplicative-expression" means
that any sequence of tokens which can parse as a multiplicative-expression
could also parse as an additive-expression, but it does not mean that every
multiplicative-expression in a parse tree is also an additive-expression.

On Sun, Sep 22, 2019 at 2:40 PM Andrew Schepler <aschepler_at_[hidden]> wrote:

>
>
> `1` is certainly an *expression* (the grammatical production) and normal
>> English word "expression" as used in the standard.
>>
>> literal > primary-expression > postfix-expression > unary-expression >
>> cast-expression > pm-expression > multiplicative-expression >
>> additive-expression > shift-expression > compare-expression >
>> relational-expression > equality-expression > and-expression >
>> exclusive-or-expression > inclusive-or-expression > logical-and-expression
>> > logical-or-expression > conditional-expression > assignment-expression >
>> expression
>>
>
> I don't agree. The token "1" can be a grammatical _expression_, but it's
> not when appearing in the context "f(n+1);". The grammar rule
> "multiplicative-expression: additive-expression" means that any sequence of
> tokens which can parse as an additive-expression could also parse as a
> multiplicative-expression, but it does not mean that every
> additive-expression in a parse tree is also a multiplicative-expression. We
> also have the rule "simple-capture: this", but we wouldn't say every
> instance of the keyword "this" is a simple-capture, only the ones which are
> used as the "simple-capture" symbol in the right side of some parent rule.
>
> And using a grammar symbol to mean any sequence of tokens, or even any
> sequence of tokens associated with a node in the grammar tree, which "could
> be parsed" as that symbol would make things worse: the tokens "int()" can
> be a postfix-expression or a type-id, but never both. Sometimes the grammar
> alone forces those tokens to be one or another, and in several other places
> an explicit disambiguation rule is needed, but clearly even in the cases
> where no disambiguation is mentioned, being a valid parse is not enough to
> make the tokens a postfix-expression or type-id.
>
>
>
>
>