| 02:11 | <jackworks> | alert() = 1 // hey that's illegal |
| 02:12 | <jackworks> | Chrome will open an alert window then ReferenceError |
| 03:00 | <Bakkot> | yeah, they compile it to something like `alert()[function(){throw new ReferenceError}() = 1` |
| 03:00 | <Bakkot> | like, in the parser |
| 03:00 | <Bakkot> | I do not expect anyone is relying on the function actually getting invoked |
| 03:00 | <Bakkot> | but who knows. |
| 20:28 | <devsnek> | is the best way to handle IterationStatement just to make a bunch of helper ast node types like "WhileStatement" |
| 20:43 | <Bakkot> | devsnek: as in, when designing your AST? |
| 20:43 | <Bakkot> | that is the usual thing to do, yes |
| 20:43 | <devsnek> | yeah |
| 21:25 | <devsnek> | > TopLevelVarDeclaredNames |
| 21:25 | <bradleymeck> | ah, the evils of delete |
| 21:25 | <devsnek> | > If Statement is Statement : LabelledStatement, return TopLevelVarDeclaredNames of Statement. |
| 21:26 | <devsnek> | isn't this circular |
| 21:26 | <devsnek> | or |
| 21:26 | <devsnek> | idk |
| 21:26 | <devsnek> | this is a very confusing part of the spec |
| 21:27 | <bradleymeck> | that looks like it shouldn't happen? *off to reread* |
| 21:28 | <bradleymeck> | it makes sense, but it doesn't specify that it needs to use the labelledstatement form of TopLevelVarDeclaredNames |
| 21:29 | <bradleymeck> | bug it looks like |
| 21:31 | <jmdyck> | It doesn't have to specify that it needs to use the labelledstatement form of TopLevelVarDeclaredNames: that'll happen automatically via the chain rule |
| 21:34 | <Bakkot> | I wonder how many new rules we would have to add to get rid of the chain rule |
| 21:34 | <Bakkot> | probably enough to make it not worth it |
| 21:34 | <bradleymeck> | jmdyck: but the chain rule isn't being applied when you get the the StatementItem: Statement form, i don't see how it would propagate here, the definition of the chain rule doesn't seem to state this would work if it is in an algorithm? |
| 21:34 | <devsnek> | there some issue in my implementation of the var scoped declarations/names stuff :( |
| 21:36 | <devsnek> | if anyone here feels confidant in their understanding of how those work my new implementations are in this folder https://github.com/engine262/engine262/tree/parser/src/static-semantics |
| 21:36 | <bradleymeck> | i just think this needs to be clarified somewhere (idc where) that it uses the LabelledStatement form. Right now it does appear to be cyclic even with me rereading https://tc39.es/ecma262/#sec-algorithm-conventions-syntax-directed-operations |
| 21:37 | <Bakkot> | devsnek: your implementation doesn't handle labeled statements? |
| 21:37 | <jmdyck> | bradleymeck: the chain rule doesn't need to 'propagate here'. It 'starts' when you need to execute "TopLevelVarDeclaredNames of |Statement|" |
| 21:37 | <devsnek> | i haven't got that far yet |
| 21:38 | <devsnek> | rn i'm stuck on var declarations not being found in VarScopedDeclarations |
| 21:39 | <bradleymeck> | jmdyck: i see |
| 21:39 | <jmdyck> | ... there isn't an explicit TopLevelVarDeclaredNames rules for `Statement : LabelledStatement`, but the latter is a chain production, so the chain rule kicks in |
| 21:40 | <bradleymeck> | jmdyck: confusing, but i understand |