| 16:49 | <jmdyck> | Jack Works: When you introduce CoverXandY, you need to use it (instead of X or Y) in those contexts where the conflict/ambiguity exists. So if you're introducing CoverExpressionStatementAndWhatever, you'd have to change the Statement production to use that instead of ExpressionStatement. I think. |
| 16:49 | <jmdyck> | Mind you, I'm not sure you should be covering ExpressionStatement. |
| 16:51 | <jmdyck> | Seems like the conflict is with a CallExpression, so you need to bolt something onto CoverCallExpressionAndAsyncArrowHead. |
| 16:54 | <Jack Works> | but when it goes into the CallExpression, it is already chosen to use ExpressionStatement. can I go back and choose a different production (MatchStatement)? |
| 16:58 | <jmdyck> | Sorry, I didn't mean a conflict with the whole of CallExpression, but rather with the part of CallExpression that CoverCallExpressionEtc deals with. |
| 16:58 | <jmdyck> | wait, no, you asked a different question. |
| 17:01 | <jmdyck> | You should look at how CoverCallExpressionEtc is used in the grammar. There's a use from CallExpression and one from AsyncArrowFunction. |
| 17:01 | <Jack Works> | Here is the full problem: For code: match (expr) if the following token is a {, then if this is parsing a statement (like "; match (expr) {"), then continue with the Match Statement otherwise continue with Match Expression (like "f(match (expr) {") if it's something else, continue with CallExpression |
| 17:03 | <Jack Works> | I cannot add lookahead != `match` to Expression Statement so it's also a syntax ambiguity between match expression and statement |
| 17:04 | <jmdyck> | Technically, I think it's a conflict, not an ambiguity. |
| 17:05 | <jmdyck> | In an ambiguity, there would be 2 different ways to parse a whole text. |
| 17:05 | <Jack Works> | oh that's correct |
| 17:06 | <jmdyck> | but it's true that you can't add [lookahead != 'match'] to ExprStmt |
| 17:06 | <Jack Works> | because there is a lookahead!=async function in ExprStmt so AsyncFnExpr won't conflict with AsyncFnDecl, in my case I cannot do this... |
| 17:07 | <Jack Works> | hmm maybe I can use the syntax parameter to do it? |
| 17:08 | <Jack Works> | ExprStmt uses ~MatchExpr, and all other references to Expr/AssignmentExpr uses +MatchExpr |
| 17:08 | <Jack Works> | then I can resolve the conflict between Match Stmt and Expr |
| 17:09 | <Jack Works> | but Stmt with Call is still a problem |
| 17:09 | <jmdyck> | hm, you need both MatchStatement and MatchExpr? |
| 17:10 | <Jack Works> | yes, at least I hope. Stmt version can contain statements, where the expression version don't. |
| 17:10 | <Jack Works> | if we have do expression, I can remove Stmt version |
| 17:11 | <jmdyck> | That complicates things, I think. |
| 17:13 | <Jack Works> | 🤔 |
| 17:15 | <jmdyck> | Isn't there an actual ambiguity between MatchStmt and MatchExpr? |
| 17:16 | <Jack Works> | hmm yes. |
| 17:16 | <jmdyck> | like if you wrote a MatchStmt but all its statements happened to be ExprStmts, wouldn't it also look like a MatchExpr? |
| 17:17 | <Jack Works> | but Stmt can only appear at a Stmt position, is that really a problem? |
| 17:18 | <jmdyck> | I think I'd have to look at the syntax for MatchStmt and MatchExpr |
| 17:18 | <Jack Works> | I hope I can prevent ExprStmt parse Expression that Expression is a sole match expr, so there is no ambiguity in that position |
| 17:19 | <Jack Works> | for this code: match (expr) { default: { x }} it's ambiguity, a block with ident ref "x" in Stmt version and an object literal in expr version |
| 17:20 | <Jack Works> | ok I admit this is not ideal either |
| 17:21 | <Jack Works> | I should discuss it in the pattern matching champion group to see if we can do things in a unified way |
| 17:23 | <jmdyck> | This is https://github.com/tc39/proposal-pattern-matching ? |
| 17:23 | <Jack Works> | for example, use this production. but this basically means we reinvented the Do Expression proposal default: Block default: [lookahead != `{`] Expression |
| 17:23 | <Jack Works> | This is https://github.com/tc39/proposal-pattern-matching ? |
| 17:24 | <jmdyck> | ok, i'll try to look at it when i get some time. |
| 17:25 | <jmdyck> | (gotta go now) |