| 04:23 | <Jack Works> | https://marketplace.visualstudio.com/items?itemName=MagicWorks.ecmarkup ecmarkup language extension for vscode. |
| 04:23 | <Jack Works> | emu-* HTML tags definition |
| 04:24 | <Jack Works> | code snippet for verbose spec clause |
| 04:25 | <Jack Works> | alg highlight (still improving) |
| 04:27 | <Jack Works> | type check & lint result from ecmarkup cli |
| 04:29 | <Jack Works> | Warning: Low performance; May crash; bugs I'm going to rewrite it in the future |
| 06:31 | <ljharb> | should it also be throw? |
| 08:13 | <bakkot> | Jack Works: very nice! |
| 08:14 | <bakkot> | ljharb: we decided no - iterator helpers only forward the iteration parts of the generator protocol, meaning calls to next and return, and not even the values passed to those things |
| 08:14 | <bakkot> | nothing in the language calls .throw |
| 08:14 | <bakkot> | so leaving it out doesn't really affect anything |
| 08:16 | <bakkot> | as I understand it .throw is part of the generator protocol mostly to explain stuff like, if you think of async functions as a fancy kind of generator, well, await can throw, so there needs to be something in the protocol which explains that |
| 08:16 | <bakkot> | which is cool and all but is not relevant to iterators |
| 15:18 | <Kris Kowal> | Yeah, indeed. Q.async straddled both the modern and old Firefox generator functions. The throw and return methods made it possible to shim async functions elegantly. https://github.com/kriskowal/q/blob/master/q.js#L1253-L1327 |