[patterns] Syntactic ambiguity

[eernstg]

The grammar rules about patterns include an ambiguity:

flowchart TD;
    A[primaryPattern] --> B[constantPattern];
    A --> C[variablePattern];
    B --> D[identifier];
    C --> D;

Loading

I would recommend that the grammar is changed such that neither <constantPattern> nor <variablePattern> can derive <identifier>, but <primaryPattern> gets a new case <identifierPattern>:

<primaryPattern> ::= <constantPattern>
                   | <variablePattern>
                   | <identifierPattern> // New.
                   | <parenthesizedPattern>
                   | <listPattern>
                   | <mapPattern>
                   | <recordPattern>
                   | <objectPattern>

<identifierPattern> ::= <identifier>

<variablePattern> ::= ( 'var' | 'final' | 'final'? type ) <identifier> // Remove `?`.

<constantPattern> ::= <booleanLiteral>
                    | <nullLiteral>
                    | '-'? <numericLiteral>
                    | <stringLiteral> // Remove `<identifier>` alternative.
                    | <symbolLiteral>
                    | <qualifiedName>
                    | <constObjectExpression>
                    | 'const' <typeArguments>? '[' <elements>? ']'
                    | 'const' <typeArguments>? '{' <elements>? '}'
                    | 'const' '(' <expression> ')'

An identifier pattern would then be disambiguated based on the context:

• In a declaration context, an identifier pattern introduces a fresh variable whose type is inferred.
• In an assignment context, an identifier pattern is a reference to a local variable.
• In a matching context, an identifier pattern is a reference to a constant variable.

[munificent]

We can do this if you really think it's worth it, but I chose the current approach because I believe it leads to a simpler specification overall. If we have both <variablePattern> (for annotated variables) and <identifierPattern> unannotated variables in irrefutable contexts, then in later sections on semantics we either need to duplicate prose or reorganize it so that the same semantics covers multiple grammar productions.

I felt it was simpler to have the grammar productions have a 1-1 correspondence with semantics and then just disambiguate the syntax early on. That way, all variable declarations in patterns are <variablePattern>, and all constants are <constantPattern>.

[eernstg]

The point is that the current grammar is ambiguous, and the parser can't decide on which derivation to use in each case.

If we have both <variablePattern> (for annotated variables) and <identifierPattern> unannotated variables in irrefutable contexts, then in later sections on semantics we either need to duplicate prose or reorganize it

The patterns spec refers to 'variablePattern' two times, total. Everywhere else it says 'variable pattern'.

So you just need to say, once, that a variable pattern is a <variablePattern> or an <identifierPattern> that occurs in a declaration context.

Similarly, a constant pattern is a <constantPattern> or an <identifierPattern> that occurs in a matching context.

There is no separate pattern for bare identifiers in an assignment context, but we could have an assignable expression pattern which would be an <identifierPattern> that occurs in an assignment context.

[leafpetersen]

I think I agree with @eernstg here that if we're going to go to the trouble to specify the grammar, we shouldn't specify a grammar that is unnecessarily ambiguous, even if it should be obvious to the implementation teams how to programmatically disambiguate it.