| 16:59 | <littledan> | shaylew: Hey do you have any sort of sketch about your "delimited continuation" ideas around AsyncContext? |
| 17:13 | <shaylew> | haven't gotten to write it down, but the very quick sketch is - following the "Delimited Dynamic Binding" paper for combining delimited continuations (which give a natural semantics to async/await and generators among other things) with dynamically bound variables https://okmij.org/ftp/Computation/dynamic-binding.html#DDBinding - in this light the main missing primitives in the current proposal seems to be "capture a snapshot _up to a particular marker_ without going all the way to the top scope" and "restore a partial snapshot _on top of the current stack_ without replacing it" - Oleg gives an extension for looking back at "shadowed" values of a variable that amounts to `variable.withOuterContext(fn)` which runs `fn` in a prefix of the current scope up to just before the innermost binding of the variable. this is strictly more powerful than just being able to read the next-outer value of the variable |
| 17:15 | <shaylew> | I want to come up with concrete motivating examples for the distinctions here, because the answers to "why do you want this and what trouble do you get into if you try to fake it" are kind of subtle |
| 17:18 | <shaylew> | ("implicit functions" from https://www.microsoft.com/en-us/research/publication/programming-with-implicit-values-functions-and-control-or-implicit-functions-dynamic-binding-with-lexical-scoping/ are one of the test cases for whether you've got things sufficiently expressive so I was thinking of trying to borrow some of their examples) |
| 17:23 | <shaylew> | the other line of inquiry is to figure out if this "capture stack segments rather than complete stacks" paradigm gets things right for the thorny real world APM situations, where it sounds like there's currently a bit of a quagmire of "oh, I want to exempt or include these specific variables from being captured/restored, but how do I know which of other people's variables should be in which category". I have less direct intuition for those situations |
| 22:45 | <Justin Ridgewell> | in this light the main missing primitives in the current proposal seems to be "capture a snapshot up to a particular marker without going all the way to the top scope" and "restore a partial snapshot on top of the current stack without replacing it" It sounds like the Variable.wrap(fn) propposal to catpure the current value of a variable and restore that later, possibly with the ability to snapshot multiple variables at once Snapshot.wrap(fn, var1, var2, var3)Oleg gives an extension for looking back at "shadowed" values of a variable that amounts to This seems like the callingContext() propopsal, which we need to discuss further. Figuring out what use cases need call-time or registration-time context is difficult, and there’s also the possibility of merge-points in Promsie.all(…) that we discussed today. |
| 23:34 | <shaylew> | right, yeah, I think this set of ideas is most directly applicable to `callingContext`, and in that case it suggests strongly that it should be using a specific variable as a stack marker, escaping up to that mark, rather than always escaping one context upwards |