add pattern matching #251
add pattern matching #251
Conversation
| } | ||
| ``` | ||
|
|
||
| ## RestMatchElement |
There was a problem hiding this comment.
The ArrayMatchPattern, ObjectMatchPattern and RestMatchElement are essentially ArrayPattern, ObjectPattern and RestElement with Pattern replaced by MatchPattern.
| ```js | ||
| interface AsMatchPattern <: MatchPattern { | ||
| type: "AsMatchPattern"; | ||
| test: MatchPattern; |
There was a problem hiding this comment.
The AsMatchPattern is separated from BinaryMatchPattern because the right (renamed as id) accepts a Pattern, not MatchPattern.
| ```js | ||
| interface BinaryMatchPattern <: MatchPattern { | ||
| type: "BinaryPattern"; | ||
| operator: "and" | "or" | "with"; |
There was a problem hiding this comment.
The champions have not decided the combinator token of "and" and "or": tc39/proposal-pattern-matching#179. We could change to & and | here if they go with these sigils.
experimental/pattern-matching.md
Outdated
| ## ExpressionMatchPattern | ||
| ```js | ||
| interface ExpressionMatchPattern <: MatchPattern { | ||
| type: "ExpressionMatchPattern"; | ||
| expression: Expression; | ||
| } | ||
| ``` |
There was a problem hiding this comment.
not sure if this is covered or not; the syntax allows ^Identifier, ^(Expression), but also things of the form ^A['B'].C() or ^A?['B']?.C?.().
There was a problem hiding this comment.
does it matter if there are parentheses or not?
There was a problem hiding this comment.
Yes; any expression can be in parens, but only a specific limited set of forms can omit them.
There was a problem hiding this comment.
the syntax allows ^Identifier, ^(Expression), but also things of the form ^A['B'].C() or ^A?['B']?.C?.().
Both ^Identifier and ^(Expression) are an ExpressionMatchPattern whose expression is an Identifier or an Expression. ESTree does not track whether parentheses are required to form a valid syntax. Instead a parser will throw when parentheses are required and a generator will add parentheses based on the AST structure.
| extend interface UnaryExpression <: Expression, MatchPattern {} | ||
| ``` | ||
|
|
||
| If a UnaryExpression is a MatchPattern, its `operator` must be `"-"`, its `prefix` must be `true`, and its `argument` must be either a Literal with numeric value, or an identifier named `"Infinity"`. |
There was a problem hiding this comment.
as a pattern, this also allows undefined (even if the identifier resolves to something that's not the undefined value), but also, all number and bigint literals (with +, -, or no sign at all), null, booleans, etc.
Also, template literals haven't been thought out here - i filed tc39/proposal-pattern-matching#205 to track
There was a problem hiding this comment.
Yeah, undefined is covered in the Identifier case
extend interface Identifier <: Expression, Pattern, MatchPattern {}
The UnaryExpression case is addressed to things like -0, -1, -1n and -Infinity, since they are an UnaryExpression from the AST perspective.
The template literals in ESTree has a specific type TemplateLiteral, in this PR the TemplateLiteral is not mentioned so it is not a MatchPattern. But yeah it is a good question whether it should be allowed. I will update this PR if necessary.
|
|
||
| If `test` is `null`, `id` must be `null`. | ||
|
|
||
| ## MatchPattern |
There was a problem hiding this comment.
Could we add a mention here as to why we don’t just use Pattern? (You mentioned in the PR itself but seems important to include here as well.)
There was a problem hiding this comment.
Sure, addressed in d67b89a.
Co-authored-by: Nicholas C. Zakas <[email protected]>
| } | ||
| ``` | ||
|
|
||
| ## 4 "if" Match Clause and Binary Match Pattern |
There was a problem hiding this comment.
Nit: missing dots here and below in headings.
| @@ -0,0 +1,373 @@ | |||
| # AST examples of [Pattern Matching ESTree Proposal](proposal-pattern-matching-estree) | |||
There was a problem hiding this comment.
Why not keep this as a section in the main .md?
There was a problem hiding this comment.
Oh the examples are not supposed to be part of the spec. They serves as an explainer only. I should have removed them before commit.
|
It's rather hard to understand which of the conversations here are still unresolved. Is there anything left? |
|
It's worth noting that the syntax is still in flux; for example, we'll probably go with |
Yeah the AST spec tries to cover all the mentioned syntax. If we drop some features when the proposal gets advanced, we can revise the AST accordingly. The experimental folder is deemed unstable and we are free to make breaking changes. I have resolved current review issues. Let me know if there's more. I am on vacation and will come back to work on it next week. |
View Rendered Text
See also AST examples for this PR.
This PR adds support to the Pattern matching proposal. Besides the
match () {}expression, the proposal introduces the concept ofMatchPattern, which has subtle differences with current destructuringPattern. I copied currentPatterndesign and infix the Node type withMatch. I am open to changes of AST structures or renaming of AST node shapes.