PEP 642: Use correct terminology for new PEG parser (#1687)

Also links to the WIP reference implementation.

pep-0642.rst

@@ -33,10 +33,10 @@ pattern syntax:
 * Literal patterns and value patterns are combined into a single new
   pattern type: "constraint patterns"
 * Constraint patterns use `?` as a prefix marker on an otherwise arbitrary
-  atomic expression: `?EXPR`
+  primary expression: `?EXPR`
 * There is no special casing of the `None`, `True`, or `False` literals
 * The constraint expression may be omitted to give a non-binding wildcard pattern
-* Mapping patterns change to allow arbitrary atoms as keys
+* Mapping patterns change to allow arbitrary primary expressions as keys
 * Attempting to use a dotted name as a match pattern is a syntax error rather
   than implying a value constraint
 * Attempting to use a literal as a match pattern is a syntax error rather
@@ -138,8 +138,8 @@ Wildcard patterns change their syntactic marker from `_` to `?`.
 Literal patterns and value patterns are replaced by constraint
 patterns.
 
-Mapping patterns change to allow arbitrary atoms for keys, rather than being
+Mapping patterns change to allow arbitrary primary expressions for keys, rather
-restricted to literal patterns or value patterns.
+than being restricted to literal patterns or value patterns.
 
 
 Wildcard patterns
@@ -164,11 +164,11 @@ Constraint patterns
 
 Constraint patterns use the following simplified syntax::
 
-    constraint_pattern: '?' EXPR
+    constraint_pattern: '?' primary
 
-The constraint expression is an arbitrary atomic expression - it can be a
+The constraint expression is an arbitrary primary expression - it can be a
 simple name, a dotted name lookup, a literal, a function call, or any other
-atomic expression.
+primary expression.
 
 If this PEP were to be adopted in preference to PEP 634, then all literal and
 value patterns would instead be written as constraint patterns::
@@ -240,7 +240,7 @@ value patterns with constraint patterns::
   mapping_pattern: '{' [items_pattern] '}'
   items_pattern: ','.key_value_pattern+ ','?
   key_value_pattern:
-      | atom ':' or_pattern
+      | primary ':' or_pattern
       | '**' capture_pattern
 
 However, the constraint marker prefix is not needed in this case, as the fact
@@ -587,13 +587,15 @@ Accordingly, the proposal was simplified to omit the marker prefix from mapping
 pattern keys.
 
 
-Restricting the permitted atoms in constraint patterns and mapping pattern keys
+Restricting permitted expressions in constraint patterns and mapping pattern keys
--------------------------------------------------------------------------------
+---------------------------------------------------------------------------------
 
 While it's entirely technical possible to restrict the kinds of expressions
 permitted in constraint patterns and mapping pattern keys to just attribute
 lookups (as PEP 634 does), there isn't any clear runtime value in doing so,
-so the PEP proposes allowing any kind of atom.
+so the PEP proposes allowing any kind of primary expression (primary
+expressions are an existing node type in the grammar that includes things like
+literals, names, attribute lookups, function calls, container subscripts, etc).
 
 While PEP 635 does emphasise several times that literal patterns and value
 patterns are not full expressions, it doesn't ever articulate a concrete benefit
@@ -606,10 +608,11 @@ that just returned their argument) to express the behaviour they wanted before
 the language definition was finally updated to allow arbitrary expressions and
 let users make their own decisions about readability.
 
-The comparable situation for PEP 634 is that arbitrary expressions are
+The situation in PEP 634 that bears a resemblance to the situation with decorator
-technically supported in value patterns, they just require an awkward workaround
+expressions is that arbitrary expressions are technically supported in value
-where all the values to match need to be specified in a helper class that is
+patterns, they just require an awkward workaround where all the values to
-placed before the match statement::
+match need to be specified in a helper class that is placed before the match
+statement::
 
     # Allowing arbitrary match targets with PEP 634's value pattern syntax
     class mt:
@@ -625,23 +628,28 @@ supporting arbitrary value constraints from the start::
         case ?func():
             ... # Handle the case where 'expr == func()'
 
-Whether actually doing that or not is a good idea would be a topic for style
+Whether actually writing that kind of code is a good idea would be a topic for
-guides and code linters, not the language compiler.
+style guides and code linters, not the language compiler.
 
 In particular, if static analysers can't follow certain kinds of dynamic checks,
 then they can limit the permitted expressions at analysis time, rather than the
 compiler restricting them at compile time.
 
+
 Reference Implementation
 ========================
 
-A reference implementation for this PEP is being derived from Brandt Bucher's
+A reference implementation for this PEP [3_] is being derived from Brandt
-reference implementation for PEP 634 [3_].
+Bucher's reference implementation for PEP 634 [4_].
 
-Relative to the text of this PEP, the draft reference implementation will
+Relative to the text of this PEP, the draft reference implementation currently
-retain literal patterns as implemented for PEP 634 (as this PEP only removes
+retains literal patterns as implemented for PEP 634 (This PEP only removes
 them as redundant given constraint patterns, it doesn't inherently conflict with
-them). Value patterns, wildcard patterns, and mapping patterns are being updated
+them, and both the tutorial in PEP 636 and the pattern matching test suite
+suggest that keeping literal patterns might be worthwhile even if the spelling
+of value matching patterns is changed).
+
+Value patterns, wildcard patterns, and mapping patterns are being updated
 to follow this PEP rather than PEP 634.
 
 
@@ -665,7 +673,10 @@ References
 .. [2] Declined pull request proposing to list this as a Rejected Idea in PEP 622
    https://github.com/python/peps/pull/1564
 
-.. [3] PEP 634 reference implementation
+.. [3] In-progress reference implementation for this PEP
+   https://github.com/ncoghlan/cpython/tree/pep-642-constraint-patterns
+
+.. [4] PEP 634 reference implementation
    https://github.com/python/cpython/pull/22917
 
 
@@ -708,9 +719,9 @@ Notation used beyond standard EBNF is as per PEP 534:
 
     capture_pattern: NAME !('.' | '(' | '=')
 
-    wildcard_pattern: '?'
+    constraint_pattern: '?' primary
 
-    constraint_pattern: '?' atom
+    wildcard_pattern: '?'
 
     group_pattern: '(' pattern ')'
 
@@ -725,12 +736,14 @@ Notation used beyond standard EBNF is as per PEP 534:
     mapping_pattern: '{' [items_pattern] '}'
     items_pattern: ','.key_value_pattern+ ','?
     key_value_pattern:
-        | atom ':' pattern
+        | primary ':' pattern
         | double_star_pattern
     double_star_pattern: '**' capture_pattern
 
     class_pattern:
         | name_or_attr '(' [pattern_arguments ','?] ')'
+    attr: name_or_attr '.' NAME
+    name_or_attr: attr | NAME
     pattern_arguments:
         | positional_patterns [',' keyword_patterns]
         | keyword_patterns