| 15:41 | <Michael Ficarra> | I think today's editor call might not be on the TC39 calendar |
| 16:24 | <ljharb> | it's not |
| 16:24 | <ljharb> | is it every monday moving forward? |
| 16:25 | <ljharb> | i have friday july 11th, and then nothing until wednesdays starting august 6th |
| 16:31 | <Michael Ficarra> | umm I can't remember if this was the new timeslot going forward or not |
| 16:32 | <Michael Ficarra> | I think so? We should confirm with Shu |
| 16:32 | <Michael Ficarra> | either way, there's no meeting next week due to plenary |
| 16:32 | <Michael Ficarra> | so we can just add this as a one-off and set the recurring one to start the week after plenary |
| 16:32 | <Michael Ficarra> | today's meeting is 13:00 Mountain time btw |
| 16:34 | <Michael Ficarra> | btw I'd like to talk about some new esmeta features at today's editor call |
| 16:36 | <jmdyck> | so ~2.5 hrs from now? |
| 16:42 | <Michael Ficarra> | yeah |
| 20:58 | <Michael Ficarra> | here's the esmeta logs I was referring to in today's editor call: https://gist.github.com/michaelficarra/8ed4c5d1243dc1465f14e90623e1c8c9 |
| 20:59 | <Michael Ficarra> | some of them are low-hanging fruit for the esmeta parser, some are low-hanging fruit for us to clean up |
| 21:05 | <jmdyck> | (I'll just point out that ecmaspeak can parse all of these.) |
| 21:56 | <jmdyck> | From what little I know about esmeta, it's harder for them because they need to declare a data structure for each different form that they parse. |
| 21:57 | <jmdyck> | Whereas ecmaspeak just has a grammar, and everything gets parsed into the same generic parse-tree structure. |
| 21:58 | <Michael Ficarra> | no I don't think that's true from how Jihyeok described it to me |
| 22:05 | <Michael Ficarra> | man, every time I look through the code, I am completely lost though |
| 22:05 | <jmdyck> | E.g., the structures declared in https://github.com/es-meta/esmeta/blob/6038a20b263d51410e1b8112157af9b1f413349e/src/main/scala/esmeta/lang/Step.scala |
| 22:06 | <Michael Ficarra> | ah, yes, but that structure is associated with many possible concrete forms |
| 22:06 | <Michael Ficarra> | see https://github.com/es-meta/esmeta/blob/main/src/main/scala/esmeta/lang/util/Parser.scala#L108-L115 |
| 22:07 | <Michael Ficarra> | anywhere there's a | or an opt means many concrete forms can parse to the same thing |
| 22:08 | <jmdyck> | sure, but presumably the "yet-steps.txt" are concrete forms that no structure corresponds to. So in order to handle them, they'll need to either declare a new structure, or generalize an existing one. |
| 22:09 | <Michael Ficarra> | so for example those "for each code point ..." loops in yet-steps.txt can be supported with just a parser change to allow more than just opt("element") here: https://github.com/es-meta/esmeta/blob/main/src/main/scala/esmeta/lang/util/Parser.scala#L131-L137 |
| 22:11 | <Michael Ficarra> | and I think they actually had just as little visibility into this as we did until recently |