| 01:50 | <jmdyck> | At the end of https://tc39.es/ecma262/#sec-asyncblockstart, there's a Note about the possible sources of _result_. What I don't understand is, if it's coming from Await, how do you know it's ~unused~? (Seems more like it would have to be an ES lang value.) |
| 01:59 | <bakkot> | it's actually empty not unused afaict |
| 01:59 | <bakkot> | but by "coming from Await", it means coming from (what is now) RunCallerContext step 4 |
| 02:00 | <bakkot> | which Await invokes in its step 8, passing empty https://tc39.es/ecma262/multipage/control-abstraction-objects.html#await |
| 02:01 | <bakkot> | I think Await should probably be passing unused there |
| 02:04 | <bakkot> | it used to in the 2022 edition, got changed sometime between then and 2023, let me see |
| 02:05 | <jmdyck> | AsyncBlockStart used to use *undefined* |
| 02:06 | <bakkot> | what I mean is, https://tc39.es/ecma262/2022/multipage/ecmascript-data-types-and-values.html#await step 10 is unused |
| 02:06 | <bakkot> | whereas https://tc39.es/ecma262/2023/multipage/control-abstraction-objects.html#await step 10 passes empty |
| 02:10 | <bakkot> | changed in https://github.com/tc39/ecma262/pull/2665 |
| 02:11 | <jmdyck> | Let me see... |
| 02:16 | <jmdyck> | When AsyncBlockStart invokes RunSuspendedContext, there's a transfer of control to asyncContext, and this note is saying that the only way control can transfer back is via Await's call to RunCallerContext, or via completion of the closure above (if there's no call to Await)? |
| 02:16 | <bakkot> | correct |
| 02:17 | <bakkot> | and that in both cases, the value which is passed when doing that transfer of control is supposed to be unused, except that in Await it's actually empty as of the above PR |
| 02:17 | <jmdyck> | What prevents some other call to RunCallerContext? |
| 02:18 | <bakkot> | the only other caller is Yield, I think? and, uh, probably nothing, I suspect that sentence predates async generators |
| 02:19 | <bakkot> | (and so became incorrect when it was added) |
| 02:19 | <bakkot> | oh, no, async generators use AsyncGeneratorStart |
| 02:20 | <bakkot> | so, what prevents it is that the only callers of RunCallerContext are Await and Yield (+variants), and AsyncFunctionStart is not used to invoke things which can Yield |
| 02:27 | <jmdyck> | RunCallerContext is invoked by GeneratorYield, AsyncGeneratorYield, and Await. So is it true that
|
| 02:33 | <bakkot> | yes |
| 02:33 | <bakkot> | or, no |
| 02:33 | <bakkot> | AsyncGeneratorStart can also call it via Await |
| 02:33 | <bakkot> | but otherwise yes |
| 02:34 | <jmdyck> | ok |
| 02:35 | <jmdyck> | AsyncBlockStart's closure can result in more than one call to Await, right? |
| 02:35 | <bakkot> | correct |
| 02:36 | <bakkot> | but only the first one returns to AsyncBlockStart |
| 02:36 | <bakkot> | subsequent ones return control to... whatever transferred control to them in the first place, which is usually (possibly always?) the promise machinery I believe |
| 02:37 | <jmdyck> | hm. |
| 02:38 | <jmdyck> | And is that machinery prepared to receive ~unused~ from Await's RCC? |
| 02:39 | <jmdyck> | sorry, currently ~empty~, but you're suggesting change to ~unused~ |
| 02:39 | <bakkot> | well, it already receives ~unused~ from AsyncBlockStart step 1.i (assuming there was at least one Await), so I would hope so |
| 02:39 | <bakkot> | but I'd need to figure out what that machinery actually is to confirm |
| 02:41 | <bakkot> | oh, it's just the Await steps 2.b and 5.b |
| 02:41 | <bakkot> | which ignore it |
| 02:41 | <bakkot> |
|
| 02:41 | <bakkot> | so, yes, they are indeed so prepared |
| 02:46 | <jmdyck> | I'm looking at the return types of RunCallerContext and RunSuspendedContext, which is the type that can be "passed back" by each's transfer of control. |
| 02:47 | <jmdyck> | Or should be that type, but isn't currently. |
| 02:51 | <jmdyck> | For RunSuspendedContext, it looks like the proper return type is a throw comp or a normal comp containing ES lang value or ~empty~ or ~unused~. |
| 02:53 | <jmdyck> | For RunCallerContext, throw comp or return comp or normal comp containing ES lang value or ~empty~ |
| 02:53 | <jmdyck> | afk |
| 03:03 | <bakkot> | that sounds right, though presumably Await should be fixed so it uses unused instead of empty, and then RunSuspendedContext would no longer include Normal Completion containing empty, yes? |
| 03:24 | <jmdyck> | yeah, I think so. |
| 03:27 | <bakkot> | really I ought to have finished https://github.com/tc39/ecma262/pull/2429 instead of closing it |
| 03:27 | <bakkot> | I will re-do the relevant bits |
| 03:28 | <bakkot> | and I guess include the other stuff we've been discussing |
| 03:29 | <jmdyck> | I was going to put it in 2962 |
| 03:33 | <jmdyck> | but I guess it could be a standalone PR |
| 03:53 | <bakkot> | opened https://github.com/tc39/ecma262/pull/3896 |
| 03:53 | <bakkot> | generally easier to review things as individual PRs than a whole bunch of changes in one PR |
| 03:53 | <bakkot> | at least when they are logically independent |
| 04:29 | <jmdyck> | okay with me, i just hope it doesn't slow things down. |
| 04:30 | <jmdyck> | I'd split 2962 into ~4 PRs if I thought it would speed things up, but I doubt it would. |
| 04:32 | <jmdyck> | or maybe it would, i dunno |
| 04:33 | <jmdyck> | opinions, editors? |
| 04:34 | <Michael Ficarra> | smaller PRs would probably speed things up, yes |
| 16:42 | <Chris de Almeida> | I canceled the editors meeting that overlapped with plenary next month. the Monday editors meeting remains (occurs after plenary that day). should that one be canceled as well? |
| 16:45 | <Michael Ficarra> | yes, no editor meetings the week of plenary |