| 20:11 | <devsnek> | directives are evaluated right |
| 20:11 | <devsnek> | not that they have any side effects |
| 20:17 | <jmdyck> | looks like it. |
| 20:18 | <jmdyck> | For them not to be evaluated, ExpressionStatement would need some kind of exception for directives. |
| 20:19 | <bradleymeck> | devsnek: yep |
| 20:20 | <devsnek> | neat |
| 20:20 | <bradleymeck> | only really matters if you get a completion value |
| 20:20 | <devsnek> | why are for loops so complex :( |
| 20:20 | <devsnek> | there are like nine different variants |
| 20:21 | <bradleymeck> | because we didn't have iterators / wanted to match other langs in syntax |
| 20:22 | <bradleymeck> | i'd be cool with a very stripped down JS spec which I think is what mark was partially asking about with engine262 dogfood coverage |
| 20:27 | <devsnek> | if you run engine262 through babel you can get it pretty low |
| 20:29 | bradleymeck | replaces for loops with Array.from({length}, why) |
| 20:29 | <devsnek> | engine262 uses a lot of iteration ngl |
| 20:31 | <ljharb> | bradleymeck: +1 to that |
| 20:31 | <bradleymeck> | Pls no |
| 20:32 | <ljharb> | :-p |
| 20:32 | <ljharb> | srsly tho |
| 20:32 | <devsnek> | reminds me of something i found in babel-parser today |
| 20:33 | <devsnek> | https://gc.gy/53910196.png |
| 20:33 | <devsnek> | `undefinedPrivateNames` is a Map |
| 20:33 | <ljharb> | lol |
| 21:06 | <devsnek> | slowly laying out for loop parsing https://gc.gy/53912157.png |
| 21:07 | <Bakkot> | devsnek don't forget `for (let = 0; let < 10; ++let)` is legal |
| 21:07 | <ljharb> | yo dawg |
| 21:07 | <devsnek> | that's one of the ones at the bottom |
| 21:07 | <devsnek> | still uncategorized |
| 21:09 | <rkirsling> | C-style for loop is totally in my top three most hated programming constructs |
| 21:09 | <devsnek> | i hate how you can't run test262 until you can parse for loops |
| 21:10 | <rkirsling> | I mean it's not altogether unreasonable to expect control flow to work XD |
| 21:10 | <devsnek> | if your control flow has 12 different productions it might be |
| 21:12 | <Bakkot> | you don't need all of them to run test262 |
| 21:12 | <devsnek> | i suppose i could search through the harness for all the ones that are used |
| 21:12 | <devsnek> | but i'll have to write this sooner or later anyway |
| 21:13 | <Bakkot> | you don't even need most of the harness files most of the time |
| 21:13 | <Bakkot> | assert.js doesn't have any I think |
| 21:13 | <Bakkot> | my guess would be the array equality ones |
| 21:14 | <shu> | c-style for loops are very fast which is why they are very good |
| 21:14 | <devsnek> | 🔥 |
| 21:15 | <ljharb> | goodness should be made fast tho, not fastness implying goodness |
| 21:15 | <Bakkot> | prs welcome :P |
| 21:15 | <shu> | ya good luck |
| 21:15 | <rkirsling> | shu: I'm not objecting to bounded iteration :p |
| 21:16 | <ljharb> | lol well v8 did it for iteration methods :-p |
| 21:19 | <shu> | wait till you hear my position on raw pointers and how fast they are |
| 21:20 | <rkirsling> | do tell |
| 21:21 | <shu> | raw pointers are not as fast as they could be because you need to dereference at least once, so they're only mostly good |
| 21:30 | <devsnek> | does anyone here really love writing for statement parsers |
| 21:30 | <Bakkot> | @devsnek yes: https://github.com/shapesecurity/shift-parser-js/blob/6776a563274992579c01dbb53789b1f032c7deed/src/parser.js#L690-L821 |
| 21:31 | <devsnek> | i was just reading that |
| 21:33 | <devsnek> | Bakkot: are for statements locationless in the shift parser |
| 21:33 | <Bakkot> | what does "locationless" mean |
| 21:34 | <devsnek> | it doesn't register a location anywhere |
| 21:34 | <Bakkot> | ah, that happens in parseStatement |
| 21:34 | <Bakkot> | https://github.com/shapesecurity/shift-parser-js/blob/6776a563274992579c01dbb53789b1f032c7deed/src/parser.js#L546-L548 |
| 21:34 | <devsnek> | recursively? |
| 21:34 | <devsnek> | oh i see nvm |
| 21:34 | <Bakkot> | it's a recursive descent parser, so... yeah I guess recursively? |
| 21:35 | <devsnek> | i forgot that Statement isn't a concrete node type |
| 21:35 | <devsnek> | that's a nice simplification |
| 21:39 | <Bakkot> | yeah the types in our AST avoid empty wrappers, mostly, with the exception of ExpressionStatement and VariableDeclarationStatement (IIRC) which need wrappers because the thing they're wrapping can appear in other contexts |
| 21:40 | <devsnek> | yeah i don't think anyone has a Statement node (hopefully) |
| 21:41 | <Bakkot> | jsexplain might |
