2025-05-05 [09:27:28.0475] Michael Ficarra: bakkot i've invited Nicolò€ to some future editor call to brainstorm ideas to make the module machinery editorially easier to understand [09:28:00.0269] great [09:28:34.0510] awesome [14:05:29.0312] new editorial convention just dropped: > do not use determiners or pronouns to refer to values from other steps (e.g. "that number"); instead uses aliases or repetition [14:19:38.0811] who said that [14:20:02.0518] what's wrong with "that number" [14:32:29.0397] you should assign it to an alias and refer to the alias instead of hand-waving at things from earlier steps [14:33:15.0015] the context of this was a PR that referred to a Unicode data file in one step and then hand-waved a reference to "that line" from the file in the next step [14:33:55.0440] also added: > assertion steps should not be necessary to understand an algorithm; a reader should interpret it the same if they are removed [14:34:10.0847] inspired by the same line, since the "prior step" there was actually an assertion step [14:34:16.0638] sometimes it is clear from context, sometimes it is not [14:34:56.0765] I can drop the convention for now or leave it in until we can discuss at editor call [14:35:05.0432] I added it because I thought it would be uncontroversial [14:38:38.0739] I would also like to add another one: > do not include unnecessary demonstrative determiners (`the String _v_` when `v` is already a String) or use demonstrative determiners as a hand-wavey way to perform a conversion [14:40:21.0542] @shuyuguo:matrix.org here was the specific line btw: https://github.com/tc39/ecma262/pull/3587/files/37ad780a824f42495276961ee32bcc2ce6c3241b#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR38582 [15:55:28.0424] I don't have a problem with "that number"; it's fine when it's clear and when not clear the problem is that it is not clear [15:56:38.0104] I also don't have a problem with `the String _v_` unless it's obvious from context that `_v_` is a string [15:57:25.0558] I agree with the assert one [16:02:15.0240] this one I think we should talk about more in editor call [16:04:09.0041] is a return value of an AO whose return type is declared obvious? is a value retrieved from a call of an AO whose return type is declared obvious? [16:05:35.0076] I mean, sometimes? [16:05:55.0221] we cannot codify "be clear" as a specific set of rules around which words to use when [16:06:51.0789] we are not going to come up with a set of rules that can tell you exactly how to write each step and we shouldn't try [16:06:56.0958] it's prose [16:11:44.0476] If someone is inclined to use `the String _v_`, they should consider `Assert: _v_ is a String` instead. [16:13:37.0912] (i.e., if the point is to reassure the reader about what `_v_` is) 2025-05-07 [09:04:59.0827] https://github.com/tc39/ecma262/issues/3588 is more evidence that the note at the bottom of that section is not sufficient [09:05:15.0160] we really need like an alternative styling or a note right next to any production that is modified in Annex B [15:43:45.0861] how about > don't use demonstrative determiners as type assertions (`the String _v_` when `v` is already a `String`) when an assertion step can be used instead [16:02:21.0382] sgtm 2025-05-08 [17:23:18.0230] neither the IEEE style guide nor the Microsoft Manual of Style say anything about pronouns/repetition so I guess I won't pursue that convention anymore [17:23:29.0651] I still don't think we'll ever actually permit a step like that though [18:11:19.0748] sorry, like "that"? [18:43:14.0374] yeah, a step that uses "that" to refer to something from a previous step instead of an alias [18:46:07.0712] also, I think you guys are taking the conventions a little too seriously [18:46:20.0078] they're just conventions, they don't bind us, just guide us [18:47:05.0139] if something is going to be a helpful guide 99% of the time, it's still a useful convention to document, and we should happily violate it whenever we feel justified [18:49:17.0135] also remember that we're going to pretty much follow these instinctively, the more important audience for the conventions is proposal authors 2025-05-11 [21:21:03.0471] GeneratorStart (https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generatorstart) invokes `generatorBody` which may be an Abstract Closure that uses the `?` macro, but it doesn't wrap it in `Completion()` [21:21:05.0497] it should, right? [21:21:08.0547] @bakkot:matrix.org [22:15:42.0269] yeah, I guess [22:16:02.0843] strictly speaking the rule about wrapping things in completions only applies to AOs, I think, but it makes sense to do it for ACs as well [05:22:49.0496] should we treat all AC call sites as if the AC returns a completion record? [05:23:06.0429] I'm thinking specifically about using prefix `!` [05:24:50.0655] I think we either need to do that or annotate their return type (and include that when describing an AC-typed parameter) [07:23:06.0947] there are not that many ACs [07:23:23.0740] especially if you ignore those passed to CreateBuiltInFunction [07:23:46.0794] I definitely do not want to treat them all as returning completions; I don't see any reason to do that 2025-05-14 [08:09:56.0531] https://github.com/tc39/proposal-idl/issues/7 [09:27:07.0572] wow that seems *really* messy [09:27:20.0455] exceptions on top of exceptions [09:27:40.0867] when so many things have a special 1-off attribute, is it really helpful? [09:55:18.0771] I'm thinking there might be a middle ground, because most of the 1-off things are things we don't really want to do in the future [09:55:34.0395] so possibly we could just enumerate those ones and then do the rest with IDL [10:37:34.0319] that doc has 78 pages [10:37:37.0925] i'm not reading that [10:40:53.0392] i'd like someone to exec summary that for me [10:41:23.0528] the issue has descriptions of the parts which are most important [10:51:22.0423] that helps, thanks [10:51:27.0786] i'm a little skeptical of the "shared infra" parts [10:51:38.0809] you'd need to write a different bindgen for JS builtins [15:37:01.0382] looks like hte IPR check is broken again [15:38:22.0686] ah, I think because ron used his work email previously and that is no longer associated with his account [15:38:29.0847] we really gotta update the check to only apply to _new_ commits [16:02:05.0760] yes, that's right. i pinged ron to re-add it to his github account. [16:05:38.0124] i added a commit that marks his spec commits as exceptions, so nothing's blocked [16:06:07.0718] he probably can't re-add it if he doesn't have access to that email account anymore [16:06:38.0178] i think you still can add it, you just can't verify it [16:06:57.0093] (but this is yet another reminder of why work emails should never be used as the primary address for open source work) [16:07:55.0452] lmao [16:42:47.0229] hmm in some of the ACs that get passed to GeneratorStart, we return `ReturnCompletion(*undefined*)`, but we can also return `NormalCompletion(~unused~)` for the same behaviour [16:43:07.0689] is there a reason we would use a `ReturnCompletion` when the value is `*undefined*`? [16:43:22.0857] it seems like we should only use it when the value *isn't* `*undefined*` 2025-05-15 [17:14:47.0887] didn't we talk about this at some length? [17:16:04.0738] returning NormalCompletion is basically saying this is the "fall off the end of the function body without hitting a return" case [17:16:17.0647] returning ReturnCompletion is basically ending with an explicit `return` [17:16:24.0915] the latter is clearer [17:17:37.0613] the only reason we even support the NormalCompletion case in the machinery is to deal with implicit returns in syntactic generators, so it's weird to rely on it for non-syntactic generators which do not have implicit returns [17:18:27.0752] 3457 changed one `ReturnCompletion(*undefined*)` to `NormalCompletion(~unused~)` [17:19:19.0297] that's not inside of an AC though [17:21:07.0798] I guess it is fair to say that we could have built-in generators match non-generators by never returning a return completion [17:21:42.0696] but the machinery which consumes those completions is pretty different so I'm not sure that symmetry makes sense [17:24:47.0166] in particular, the machinery which consumes completions for built-in functions (https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-built-in-function-objects-call-thisargument-argumentslist) is not the same as the machinery which consumes completions for ES functions (https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-call-thisargument-argumentslist), whereas for generators it's the same machinery in either case (https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-generatorstart) [17:40:17.0109] alright, well leave your opinion on the PR then [17:40:34.0964] I've opened a few PRs related to completion records and ACs as discussed at editor call: https://github.com/tc39/ecma262/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen+author%3Amichaelficarra [17:54:34.0291] hm so I think some of the generator stuff might be broken actually [17:55:34.0470] ah, wait, nevermind it's fine, just kind of weird [17:56:03.0638] GeneratorStart does Evaluation of a FunctionBody parse node, which I was thinking should be https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-evaluatefunctionbody but it's actually not [17:57:25.0695] it just falls through to Evaluation of the FunctionStatementList [17:57:33.0770] which is also how EvaluateFunctionBody works: https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-evaluatefunctionbody [18:10:36.0261] ok, so, we have four kinds of function: ordinary/async/generator/async+generator [18:10:49.0147] for each of these, we have to handle throw completions, return completions, and normal completions [18:20:28.0122] right now, evaluating any of them produces either a throw completion or a return completion. for ordinary functions this is handled by translating normal completions to `ReturnCompletion(*undefined*)` in EvaluateFunctionBody: https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-evaluatefunctionbody the others explicitly return a return completion holding the promise (for async functions) or generator object (otherwise). Then [[Call]] handles the two cases (throw completion and return completion) explicitly https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-ecmascript-function-objects-call-thisargument-argumentslist. I am tempted to say that instead EvaluateFunctionBody should translate return completions into normal completions, so that evaluating the other bodies can return a normal completion. this is what the async generator machinery does, in AsyncGeneratorStart step 4.i https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-asyncgeneratorstart [18:21:04.0242] @bakkot:matrix.org here's your answer to the desired semantics for compound assignment https://github.com/tc39/test262/pull/4459/files#diff-02f5df894e79077a1cab224a19f7489864719a2fcf3e821674c4eaa06a099159 [18:21:25.0663] nice 2025-05-16 [10:58:36.0361] Michael Ficarra https://github.com/tc39/ecma262/pull/3576 now includes your new keyboard shortcut [10:58:53.0135] I wanted to get it in before the meeting so we could mention it in the slides because otherwise no one will know [11:02:28.0791] awesome [11:02:59.0014] I mean, it's in the help modal... [11:03:21.0057] no one randomly hits the help button 2025-05-20 [09:43:38.0543] module namespace exotic objects should define their `[[SetPrototypeOf]]` as the immutable prototype exotic object `[[SetPrototypeOf]]` so that they're considered immutable prototype exotic objects [09:49:32.0051] I'll send a PR [10:00:57.0119] ... but why [10:00:59.0113] you will also need to update the note: > Unlike other exotic objects, there is not a dedicated creation abstract operation provided for immutable prototype exotic objects. This is because they are only used by %Object.prototype% and by host environments [10:05:23.0169] yeah there will be a couple places to update [11:01:31.0819] why are you doing this? [11:04:22.0719] i'm not sure what value immutable prototype exotic objects provide, other than as a shorthand for "it's like a normal object, except [[SetPrototypeOf]] is overridden" [11:04:35.0823] and your proposed change would make it also lose that notion [11:04:47.0166] since module namespace exotic objects override the other internal methods itself [12:05:48.0535] is there any reason https://tc39.es/ecma262/2025/#sec-createiteratorfromclosure requires generatorPrototype to be an Object, vs "an Object or null"? (or is the reason just, we don't send it null ever) [12:07:04.0306] not that i recall, but having the narrowest type for how it's used is something we generally do, yes [12:08:41.0874] for this particular AO, creating a generator object with a null prototype seems like it'd always be an error, no? [12:40:47.0950] it just means "[[SetPrototypeOf]]" has this special behaviour, which is also true of module namespace exotic objects [12:41:27.0440] if you asked anyone whether module namespace exotic objects were immutable prototype exotic objects, they would say yes, but due to a technicality in the way we specified it, it's not actually the case [12:42:18.0123] because it's not "the same" definition, even though it's defined using the same steps [13:29:24.0733] i think the answer "anyone" would respond with is "what are immutable prototype exotic objects"? [13:29:28.0680] * i think the answer "anyone" would respond with is "what are immutable prototype exotic objects?" [13:34:35.0593] as one of the very few people in the world who actually does have familiarity with the term, I would have told you it refers to Object.prototype, and possibly the HTML windowproxy [13:35:00.0599] namespace exotic objects have immutable prototypes but "immutable prototype exotic object" means Object.prototype to me [13:56:39.0808] if anything i'd rather we remove the concept of "immutable prototype exotic object" at all [14:07:21.0330] > An object is an immutable prototype exotic object if its [[SetPrototypeOf]] internal method uses the following implementation. Its other essential internal methods may use any implementation, depending on the specific immutable prototype exotic object in question. [14:07:25.0327] it doesn't get much more clear than that [14:07:51.0265] that should apply to module namespace exotic objects [14:08:16.0463] PR is here: https://github.com/tc39/ecma262/pull/3611 [14:18:57.0636] it does get clearer: you don't need to think of them as a special object [14:19:08.0239] you just think of them as having a certain implementation of [[SetPrototypeOf]] [14:19:22.0592] i don't see what we get out of assigning a term to objects with that certain implementation [14:20:14.0089] like, the information you're trying to communicate is "[[SetPrototypeOf]] has this behavior". why not communicate that directly instead indirectly by first defining "the set of objects with [[SetPrototypeOf]] with that behavior is called X"? [14:23:18.0953] * like, the information you're trying to communicate is "\[\[SetPrototypeOf\]\] has this behavior". why not communicate that directly instead of indirectly by first defining "the set of objects with \[\[SetPrototypeOf\]\] with that behavior is called X"? [15:12:10.0357] with the PR we do both [15:12:31.0498] we link to the implementation and we give those kinds of objects a name [16:01:01.0923] i am questioning the value of giving those kinds of objects a name [16:02:32.0779] given that we already do, we should use it for all the things it describes [16:02:53.0039] it's in a very weird state right now where the term applies to only some of the things that have the property [16:03:24.0358] I would make this change and then consider the usefulness of the term later [16:03:38.0552] but I think the term is probably something that at least the committee finds useful [16:03:52.0317] i have doubts about that the status quo is really that desirable 2025-05-21 [21:00:49.0139] multiple delegates have expressed interest in making immutable prototype exotic objects a user-exposed thing [21:22:34.0262] I am interested in exposing the capability to freeze prototypes of objects without freezing the object entirely [21:22:53.0705] but I would not have the resulting things be called "immutable prototype exotic objects" [09:35:59.0347] might as well call it best exotic marigold hotel 2025-05-22 [17:48:19.0726] Michael Ficarra: In #2962, I definitely meant 2681, not 2618. However, 2618 is relevant, so I added it to the intro comment (under "Resume+Suspend"). 2025-05-23 [12:26:55.0719] at the editor call we talked about https://github.com/tc39/ecma262/pull/3606 [12:27:18.0395] and making it so that built-in generators/iterators/async functions always return `NormalCompletion(*undefined*)` [12:27:24.0480] I still think this is the right thing to do [12:28:12.0549] however, the PR updates the machinery to assert that they never return a return completion, and this is not true because `.return` can inject a return completion wherever we use the Yield macro [12:28:31.0502] * however, the PR updates the machinery to assert that they never return a return completion, and this is not true for the iterator case because `.return` can inject a return completion wherever we use the Yield macro [12:28:36.0603] * and making it so that built-in generators/async functions always return `NormalCompletion(*undefined*)` [12:28:43.0361] * however, the PR updates the machinery to assert that they never return a return completion, and this is not true for the generator case because `.return` can inject a return completion wherever we use the Yield macro [12:28:50.0810] this sucks and I hate it [12:30:11.0276] options: restore the machinery so that built-in generators can handle all three kinds of completion, update our use of the Yield macro to explicitly handle return completions wherever it's used, or switch to the other PR which made them all return ReturnCompletions instead and then not handle the NormalCompletion case [12:30:41.0174] my preference is the first but I could be persuaded that the second is better [12:30:55.0022] second ends up being a fair bit of boilerplate though 2025-05-30 [07:52:54.0015] FYI i will only be around for the first 15min next wed