| 03:39 | <jmdyck> | devsnek: ping |
| 04:16 | <devsnek> | jmdyck: hi |
| 04:17 | <jmdyck> | I wanted to talk to you about generators etc |
| 04:18 | <devsnek> | aight |
| 04:20 | <jmdyck> | the other day, you saus that the spec doesn't have suspendable abstract ops, but I'm looking at https://tc39.es/ecma262/#sec-generatorresume step 9 |
| 04:21 | <devsnek> | what about it |
| 04:22 | <jmdyck> | that suspends the execution of the GeneratorResume op, and resumes the execution of some other suspended op |
| 04:22 | <devsnek> | it suspends the execution of the entire context |
| 04:22 | <jmdyck> | yes |
| 04:23 | <devsnek> | what i meant was, we don't have the ability to suspend just the op |
| 04:23 | <devsnek> | without the surrounding context |
| 04:23 | <jmdyck> | ah, ok. |
| 04:25 | <jmdyck> | so you think of the context as 'surrounding' the execution of the op? |
| 04:28 | <devsnek> | jmdyck: that seems to be how we've specified it |
| 04:31 | <jmdyck> | I ask because there are definitely ops that execute before there are any contexts, and ops that create contexts, and ops that manipulate contexts, which suggests that ops run 'off to the side'. But then there's other stuff that suggests they run 'inside' contexts. |
| 04:32 | <jmdyck> | But the spec doesn't really demarcate that shift in perspective. |
| 04:35 | <jmdyck> | Anyway, that's a tangent. |
| 04:35 | <jmdyck> | The other thing I was looking at was https://tc39.es/ecma262/#sec-generatoryield |
| 04:36 | <devsnek> | this was also interesting https://github.com/tc39/ecma262/pull/1748 |
| 04:41 | <jmdyck> | So GeneratorYield (as written) is basically just bookkeeping: it sets some things, pops the context stack, and returns. But the thing is, according to the note in step 10, it doesn't return to the operation that called it. This is very odd. |
| 04:42 | <jmdyck> | I mean, I understand that there has to be a transfer of control, but to accomplish it via a Note that just says the return goes where you don't expect it, just seems so weird. |
| 04:43 | <devsnek> | the note is for clarity, its not normative |
| 04:44 | <jmdyck> | right, but if you deleted it, what would tell you that the return isn't to the op's caller, like every other op? |
| 04:45 | <devsnek> | i'm guessing some prose somewhere? |
| 04:47 | <jmdyck> | Well, there's no prose that talks about GeneratorYield's return semantics. |
| 04:47 | <jmdyck> | The only references to GeneratorYield are invocations. |
| 04:48 | <jmdyck> | (no prose other than that Note) |
| 04:48 | <devsnek> | hopefully something somewhere describes how suspending an execution context works |
| 04:48 | <jmdyck> | Yeah, I don't think there is. |
| 04:50 | <jmdyck> | (Another tangent: when the spec says to Suspend a context, it auto-links to https://tc39.es/ecma262/#sec-suspend which is an Atomics op.) |
| 04:50 | <devsnek> | yeah that confused me a lot |
| 04:50 | <devsnek> | back when i was first setting up generators |
| 04:52 | <jmdyck> | Well, the clause on execution contexts does talk a little about suspending |
| 04:54 | <jmdyck> | but not enough to infer anything about GeneratorYield. |
| 04:58 | <jmdyck> | It seems to me that GY should have an explicit transfer of control (suspend itself), and then wait to be resumed (with a value). And then return (as usual) to the op that called GY. |
| 04:58 | <jmdyck> | Pretty much like GeneratorResume does. |
| 05:00 | <devsnek> | i wouldn't be against refactorings of how suspension works |
| 05:02 | <jmdyck> | One thing though, AsyncGeneratorYield has a similar weirdness. |
| 05:03 | <jmdyck> | And I think it could be unweirded in a similar way, but I'm not clear on what happens in AsyncGeneratorResolve. |
| 05:04 | <jmdyck> | AsyncGeneratorResolve calls AsyncGeneratorResumeNext, which *has* an explicit xfer of control, except it seems to be going in the other direction, so I'm confused. |
| 05:05 | <jmdyck> | does engine262 implement async generators? |
| 05:06 | <devsnek> | yes |
| 05:06 | <jmdyck> | Hm, getting late here. I'm heading off, but I'll check the log for any further thoughts you might have. |
| 05:06 | <jmdyck> | thanks |
| 15:33 | <jackworks> | ah Why deref() for WeakRef, not a getter `ref`? |
| 15:46 | <bendtherules> | I have a small nitpick - In array.map (https://tc39.es/ecma262/#sec-array.prototype.map), the note says that new elements in array are not considered after map starts. But a similar note in array.foreach doesn't have that part of the note (ignores new elements) - even though that is how it operates. |
| 15:46 | <bendtherules> | Is this a miss? |
| 15:48 | <bendtherules> | Like what is the general guideline about notes? |
| 15:48 | <bendtherules> | Some sections have good understandable notes, others are very sparse. Is it mostly dependent on the proposal writer? |
| 16:38 | <rkirsling> | bendtherules: it does seem like it should be there -- as it turns out, it WAS there in ES5 but was removed as of ES6: see https://www.ecma-international.org/ecma-262/5.1/#sec-15.4.4.18 followed by http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.foreach |
| 16:39 | <rkirsling> | not sure if there would be notes of such a change but you could submit an editorial PR if you wanted |
| 16:40 | <rkirsling> | (chances are it'd get merged; at worst you'd find out why :) ) |
| 16:43 | <bendtherules> | Haha. Ok, I'll raise one |
| 17:51 | <bendtherules> | Done. PR - https://github.com/tc39/ecma262/pull/2076, issue - https://github.com/tc39/ecma262/issues/2075. |