| 22:16 | <Steve Hicks> | I was thinking a bit more about this. In my diagrams, merge points generally have a solid line and a dashed line going into them. The solid line represents the causal (or "flow") context, while the dashed like is what I'd call the lexical context. For an await, flow context is "flow-through", while lexical context is "flow-around". For a callback, flow context is "call-time", while lexical context is "registration-time". The current proposed semantics are heavily tilted toward merging into the lexical context, while Stephen is advocating for merging into the flow context. Is there any way we can put these two contexts on more equal footing? I think the one obvious option to me would be to define two types of async variables: LexicalVariable and FlowVariable, and at any given merge point, we copy the flow context from the flow side and the lexical context from the lexical side. I'm not seeing any other way to unite these two defaults... does anyone else? |
| 22:23 | <littledan> | Here in A Coruña at the Igalia Web Engines hackfest, we got a chance to talk with Anne van Kesteren, who continues to have the (personal, not necessarily Apple) position that we should consistently run all callbacks at registration time, unless we can explain a very strong reason, because this will be the most regular guarantee for developers and simplest to specify and implement. Flow variables require a lot of bookkeeping at a lot of points scattered through the specs, and it is unclear how js devs should even build a mental model around them, it could be argued |
| 22:25 | <littledan> | I was thinking a bit more about this. In my diagrams, merge points generally have a solid line and a dashed line going into them. The solid line represents the causal (or "flow") context, while the dashed like is what I'd call the lexical context. For an |
| 22:27 | <littledan> | Anne was also not 100% on the motivation for the whole feature, so that may point to room for improvement in documentation |
| 22:37 | <Chengzhong Wu> | Yeah, agreed that two type of variables could be a solution. Did you have a chance talking about run(value, fn) vs set(value) styles? Would it be too conservative to have strong scope guarantee in Web API designs? |