| 06:35 | <nicolo-ribaudo> | The problem is that this is not just a graph, but each node has also a ton of different states, and for evaluation they are _all_ relevant |
| 06:36 | <nicolo-ribaudo> | I do have an interactive example (linked to in that PR), maybe I could join the next editors call and we could consider how to embed smaller versions of it in the spec, together with the existing examples? |
| 08:52 | <nicolo-ribaudo> | shu Maybe another approach would be to make [[Status]] an enum with a payload, like Rust enums, so that the various slots are only available when they are relevant, and they transition more atomically. e.g. given that [[AsyncEvaluationOrder]] is only relevant while a module is evaluating-async, it would be used as |
| 08:52 | <nicolo-ribaudo> | Or like, [[EvaluationError]] would be defined on the EvaluatedState Record |
| 08:56 | <nicolo-ribaudo> | Or maybe we could draw some sort of state machine representing the various valid intermediate states that modules go through during the process, and how they transition between them |
| 09:53 | <nicolo-ribaudo> | I opened a PR with a test262 test for a top-level await case that was not previously covered, if anybody has time please review :) https://github.com/tc39/test262/pull/4465 |
| 15:14 | <shu> | it'd be very late for you in CET, but would be appreciated |