TC39 Async Context on 2024-07-04

01:17	<snek>	oh yeah I thought we'd use the execution context to hold this kind of thing wouldn't that mean every time the execution context changes we need to copy the value over
01:21	<snek>	wrt number of variables... should we put bounds on the algorithmic complexity of variable.run/get like we do for Map/Set?
02:40	<littledan>	wrt number of variables... should we put bounds on the algorithmic complexity of variable.run/get like we do for Map/Set? You mean, tell everyone they are expected to optimize for >100 variables? I am not sure; maybe it is OK for people to decide that they are slow. We don’t do this for objects.
02:40	<snek>	well specifically just because we specify them with lists
02:40	<littledan>	wouldn't that mean every time the execution context changes we need to copy the value over I think in this throw case you don’t want to copy
02:41	<littledan>	well specifically just because we specify them with lists What if we include a note saying “btw you can implement this with a hamt”
02:45	<snek>	Maps must be implemented using either hash tables or other mechanisms that, on average, provide access times that are sublinear on the number of elements in the collection. The data structure used in this specification is only intended to describe the required observable semantics of Maps. It is not intended to be a viable implementation model.
02:46	<snek>	something like this could be reasonable i think
02:46	<snek>	i guess i can open an issue
03:02	<Steve Hicks>	wrt number of variables... should we put bounds on the algorithmic complexity of variable.run/get like we do for Map/Set? My understanding is that v8 is intending to actually use a linked list, under the assumption that the number will be pretty small, so requiring sublinear complexity may be a (bit of a) nonstarter for them.
03:02	<snek>	they're planning to start with a linked list but they've outlined a few other implementation strategies to try next
03:03	<snek>	either way, if we expect react apps to have 100 of these, O(n) might not be great
03:04	<Steve Hicks>	wouldn't that mean every time the execution context changes we need to copy the value over IIUC, it would make function calls slightly more expensive (one more pointer to copy) but async context switches less expensive. But since function calls are likely more common, it seems like the right trade-off to put it on the agent record.
03:07	<Steve Hicks>	either way, if we expect react apps to have 100 of these, O(n) might not be great Even if there's 100s, if they're not all active at once it may not matter. I'd expect any variables involved in rendering one component shouldn't escape into unrelated calls (under the current flow-around semantics).
03:07	<Steve Hicks>	But I'm not against speccing defensively here
11:01	<littledan>	I think we should not spec asymptotic behavior here. First priority for engines should be to optimize the <100 common case. Better to just make a suggestion in a note.
11:01	<littledan>	they're planning to start with a linked list but they've outlined a few other implementation strategies to try next Note that they = Andreu and Chengzhong ;)