2022-07-05 [09:30:28.0818] shouldn't `var r = Proxy.revocable({}, {}); r.revoke(); Array.isArray(r)` throw, per spec? it doesn't in jsc or v8 or firefox. what am i missing? [09:33:40.0748] ljharb: you want `Array.isArray(r.proxy)` [09:33:42.0831] which does throw [09:33:48.0181] ahhh thanks [09:34:04.0434] knew i had to be missing something :-) [09:36:48.0206] does look like the error message is wrong tho for `var r = Proxy.revocable({}, {}); r.revoke(); Object.prototype.toString.call(r.proxy)` in jsc and v8. filed https://bugs.webkit.org/show\_bug.cgi?id=242342 and https://bugs.chromium.org/p/v8/issues/detail?id=13037 ¯\\\_(ツ)\_/¯ [09:36:49.0571] * does look like the error message is wrong tho for `var r = Proxy.revocable({}, {}); r.revoke(); Object.prototype.toString.call(r.proxy)` in jsc and v8 [09:39:51.0174] * does look like the error message is wrong tho for `var r = Proxy.revocable({}, {}); r.revoke(); Object.prototype.toString.call(r.proxy)` in jsc and v8. filed https://bugs.webkit.org/show_bug.cgi?id=242342 and https://bugs.chromium.org/p/v8/issues/detail?id=13037 ¯\_(ツ)_/¯ [09:39:54.0740] * does look like the error message is wrong tho for `var r = Proxy.revocable({}, {}); r.revoke(); Object.prototype.toString.call(r.proxy)` in jsc and v8. filed https://bugs.webkit.org/show\_bug.cgi?id=242342 and https://bugs.chromium.org/p/v8/issues/detail?id=13037 ¯\\\_(ツ)\_/¯ [10:23:26.0910] The July TC39 plenary meeting is two weeks away. This is a gentle reminder that the deadline for adding agenda items that are requesting stage advancement is in less than 4 days time! July 9th, 10:00 PDT We have a capacity for 15 hours of content during the meeting. Currently we have 4 hours of content, meaning there are 11 hours unallocated. I encourage you to add items to make good use of the time. Content additions after the deadline are also possible but may not qualify for stage advancement. There are currently 14 remaining in-person places available. So if you intend to attend in-person, please fill in the In-Person Reservation Form soon. https://github.com/tc39/Reflector/issues/437 2022-07-06 [06:54:28.0349] 👀 I want to do a temperature check on the range proposal (discussion https://github.com/tc39/proposal-Number.range/issues/17 ) Do you think it should be a Iterator (1️⃣) or an Iterable object (🔢)? 2022-07-07 [08:04:30.0283] Can you explain what are the tangible implications of choosing Iterator here? [08:31:45.0850] > <@jackworks:matrix.org> 👀 I want to do a temperature check on the range proposal (discussion https://github.com/tc39/proposal-Number.range/issues/17 ) > > Do you think it should be a Iterator (1️⃣) or an Iterable object (🔢)? I generally prefer Iterable, so that a range can be reused: ```js const oneToTen = Number.range(1, 10); // prints: 1\n2\n... for (const x of oneToTen) console.log(x); // prints: ??? for (const x of oneToTen) console.log(x); ``` Its rare that someone will manually step through an iterator rather than use `for..of` or `...`, and the latter will exhaust the iterator, making a range useless after it has been used once. If you need to step over it manually, you could still use `Symbol.iterator`, so Iterable is vastly more flexible. That said, the iterator helpers proposal depends on Iterator (which I still disagree with in principle), but relevant methods could be lifted to a Range as well. I'm still hoping we could someday have a standalone range/slice syntax like `a..b`, though that can (hopefully) come later. [08:32:52.0746] * I generally prefer Iterable, so that a range can be reused: ```js const oneToTen = Number.range(1, 10); // prints: 1\n2\n... for (const x of oneToTen) console.log(x); // prints: ??? for (const x of oneToTen) console.log(x); ``` Its rare that someone will manually step through an iterator rather than use `for..of` or `...`, and the latter will exhaust the iterator, making a range useless after it has been used once. If you need to step over it manually, you could still use `[Symbol.iterator]()`, so Iterable is vastly more flexible. That said, the iterator helpers proposal depends on Iterator (which I still disagree with in principle), but relevant methods could be lifted to a Range as well. I'm still hoping we could someday have a standalone range/slice syntax like `a..b`, though that can (hopefully) come later. [08:32:53.0180] * I generally prefer Iterable, so that a range can be reused: ```js const oneToTen = Number.range(1, 10); // prints: 1\n2\n... for (const x of oneToTen) console.log(x); // prints: ??? for (const x of oneToTen) console.log(x); ``` Its rare that someone will manually step through an iterator rather than use `for..of` or `...`, and the latter will exhaust the iterator, making a range useless after it has been used once. If you need to step over it manually, you could still use `Symbol.iterator`, so Iterable is vastly more flexible. That said, the iterator helpers proposal depends on Iterator (which I still disagree with in principle), but relevant methods could be lifted to a Range as well. I'm still hoping we could someday have a standalone range/slice syntax like `a..b`, though that can (hopefully) come later. [08:34:19.0837] (and I am not very good at avoiding work when I'm supposed to be on PTO) [09:58:31.0616] you can reuse it by sticking ()=> in front of it [10:05:32.0054] That's not reuse, that's recreating it each time. It also potentially reevaluates each argument, which could have side effects/performance implications. [10:07:35.0485] i.e., `const r = () => Number.range(0, f())`. Beginners could easily overlook the `f()` [10:09:08.0225] Maybe PFA could help, but it's also not something a beginner would likely reach for immediately, nor is the `() =>` trick [10:14:22.0364] My mental model is aligned with rbuckton (PTO: 7/5 - 7/16) - `oneToTen` should produce an iterator when used in a loop. I probably am projecting how Rust does it where `Range` implements `IntoIterator` [10:20:24.0540] i don't think beginners will expect to reuse it either tho. [10:37:54.0187] I think beginners are more likely to reuse it than not, just as you could reuse an array, or map, or set, or typed array. This is especially true if we do ever have a range/slice syntax in the future. [10:41:08.0250] I'm still of the opinion that the iterator helpers proposal has a very short-sighted view by focusing on Iterator and not Iterable, and I'd rather not repeat the mistake of leveraging the wrong level of abstraction in more places if we can potentially avoid it. That said, Iterator is probably fine for `Number.range()` on its own, but I would be strongly opposed to the same behavior for any potential Range/slice syntax in the future. [10:57:18.0677] sidebar: I am now ~half of the agenda items for the next meeting. hope everyone is prepared to talk about dumb corner cases for an entire meeting. [11:08:53.0451] please cover them on wednesday, when i cannot be there [11:32:39.0229] iterable isn’t a thing, it’s a trait. [11:32:57.0609] whereas an iterator is a thing [12:37:25.0846] > <@bakkot:matrix.org> sidebar: I am now ~half of the agenda items for the next meeting. hope everyone is prepared to talk about dumb corner cases for an entire meeting. I will add an item on Temporal, but unfortunately it's also all dumb corner cases [12:56:57.0922] Are people thinking of breakout sessions for the upcoming TC39 meeting, given our possibly somewhat light schedule when finally meeting partly in person/hybrid? [12:57:09.0019] * Are people thinking of breakout sessions for the upcoming TC39 meeting, given our possibly somewhat light schedule when finally meeting partly in person/hybrid? [12:58:48.0390] I could imagine one breakout session on modules, one on inclusion, and maybe one on Ecma, if people are interested. I imagine that other people may have other interesting topics. [13:00:18.0055] (For what it’s worth, I am still planning to add along with Hemanth H.M three agenda items for a once function, a memoize function, and built-in cache maps/sets, so the agenda will fill up a little more than it is now. I might also fill in more time with some chartered incubator topics that haven’t yet had their incubator meetings, like Array.fromAsync, BigInt Math, bind-this and pipe/topic. I’m not sure whether those would be more appropriate as breakout sessions or as ordinary agenda topics.) [13:01:01.0550] * (For what it’s worth, I am still planning to add along with Hemanth H.M three agenda items for a once function, a memoize function, and built-in cache maps/sets, so the agenda will fill up a little more than it is now. I might also fill in more time with some chartered incubator topics that haven’t yet had their incubator meetings, like Array.fromAsync, BigInt Math, bind-this and pipe/topic. I’m not sure whether those would be more appropriate as breakout sessions or as ordinary agenda topics.) [13:01:21.0460] oh yes please keep adding agenda items! those definitely are higher priority than the open-ended discussions I was suggesting. [13:02:37.0954] Some of the incubator topics are, for better or for worse, open-ended, especially discussion regarding dataflow syntaxes (including pipe/topic and bind-this). Also, I didn’t get to mention this at last plenary, but it’s good to see you again; hope you had a good past year. [13:02:51.0645] yeah good to see you too! [13:02:52.0999] I'd suggest that overflow incubator items could be breakout sessions, rather than agenda items [13:03:20.0021] (I mean, unless someone really does want to present a proposal for them) [13:07:46.0276] > <@jschoi:matrix.org> (For what it’s worth, I am still planning to add along with Hemanth H.M three agenda items for a once function, a memoize function, and built-in cache maps/sets, so the agenda will fill up a little more than it is now. I might also fill in more time with some chartered incubator topics that haven’t yet had their incubator meetings, like Array.fromAsync, BigInt Math, bind-this and pipe/topic. I’m not sure whether those would be more appropriate as breakout sessions or as ordinary agenda topics.) those new proposals sound interesting! they seem like tricky things to make built-in since caches/memoization sometimes have domain-specific retention policies; are you proposing hooks for those? [13:07:54.0518] As champion / co-champion of four out of the five chartered incubator items (https://github.com/tc39/incubator-agendas/issues/25), I do not plan to advance any of them next meeting, haha. There’s just too much contention around them right now. But maybe decorator metadata might be ready… [13:08:37.0093] of course once should be a template tag, ```once`${f}`(x)``` to take advantage of location-based caching ;) [13:08:49.0186] * of course once should be a template tag, `once``${f}``(x)` to take advantage of location-based caching ;) [13:09:02.0602] * of course once should be a template tag, ```once`${f}`(x)``` to take advantage of location-based caching ;) [13:09:04.0982] > <@littledan:matrix.org> those new proposals sound interesting! they seem like tricky things to make built-in since caches/memoization sometimes have domain-specific retention policies; are you proposing hooks for those? Oh yeah, that’s the third proposal: maps and sets with cache-replacement policies, for the sake of memoizing but also other stuff. I’m undecided whether to bundle memoization with CRP maps/sets into one proposal or not; I think we’re going to probably separate them. [13:09:35.0043] I'm glad to see that you've gotten more involved over the past year! [13:09:55.0273] https://github.com/js-choi/proposal-function-memo https://github.com/js-choi/proposal-policy-map-set [13:09:59.0195] Yeah, thanks! [13:10:29.0475] jschoi: apologies, doesn't look like i'll have enough cycles this cycle to do an incubator call :( [13:12:00.0839] Yeah, it’s no problem; I think we’re all very thankful of you managing the incubators. Hopefully we’ll knock some stuff out during plenary. [13:13:09.0611] yes, might be a good one to do it with such a light schedule [14:07:22.0205] > <@ljharb:matrix.org> iterable isn’t a thing, it’s a trait. That's the case in every language/library that is prior art for iterator helpers. Python has itertools. C# has Enumerable+extension methods. F# has pipelines (and so will we). All operate on the "Iterable" not the "iterator". [14:17:38.0160] Java's streams are pretty similar to iterators and are where all of Java's equivalents of these methods are. [14:20:09.0527] also Rust's methods are all on the Iterator trait [14:20:46.0800] Boost (the C++ library) has `filter_iterator` and so on which are, obviously, on iterators [14:21:03.0498] * Boost (the C++ library has `filter_iterator` and so on whic are, obviously, on iterators [14:21:08.0994] * Boost (the C++ library) has `filter_iterator` and so on whic are, obviously, on iterators [14:21:35.0635] * Boost (the C++ library) has `filter_iterator` and so on which are, obviously, on iterators [14:23:09.0590] Scala's AbstractIterator has `filter` and so on [14:23:14.0598] I dunno I feel like this is a lot of languages [14:23:55.0116] * Scala's AbstractIterator has `filter` and so on [14:34:24.0713] If range returned an iterator could the return value still include additional properties (start, end, step), similar to if it returned a “range instance”? Or should it only have next? [15:10:31.0100] prior art is informative, not constraining, and never automatically the right choice for JS. [16:29:28.0224] absolutely it could; whether it should is a different question 2022-07-08 [23:27:21.0425] All I know is, if you try to reuse it in Rust, it will be rejected by the compiler 😂 ```rust fn main() { let a = (1..5).into_iter(); // for i in &a {} NOT WORK for i in a {} for i in a {} // Error: Use moved value a } ``` [00:16:12.0250] In general, iterators aren’t reusable, with very few exceptions (notably, builtins like array) - i just don’t think people are going to consistently have the intuition that they will be. [04:02:08.0646] For those who will be in SF for TC39 in 12 days time, @sffc has organized a Community event on the Wednesday 20th evening at 17:30. https://github.com/tc39/Reflector/issues/437#issuecomment-1177199594 Please let Shane know if you would like to give a presentation or participate in the panel. [04:03:39.0948] Also, if you wish to put an item on the Plenary agenda for stage advancement, you have a little over 24 hours to do so. https://github.com/tc39/Reflector/issues/437#issuecomment-1178843643 [07:33:23.0693] > <@jackworks:matrix.org> All I know is, if you try to reuse it in Rust, it will be rejected by the compiler 😂 > > ```rust > fn main() { > let a = (1..5).into_iter(); > // for i in &a {} NOT WORK > for i in a {} > for i in a {} // Error: Use moved value a > } > ``` but you can do: ```rust fn main() { let a = 1..5; for i in a {} // implicitly calls into_iter() for i in a {} // implicitly calls into_iter() } ``` [08:26:46.0568] Looks like the TC39 calendar and the agenda page disagree on when the agenda deadline is [08:27:13.0734] Should we say that the agenda page is authoritative here? That one is later (tomorrow) [08:50:57.0104] The agenda is authoritative. [10:06:52.0227] i'll fix the calendar, not sure where the current deadline event came from [10:36:49.0264] thanks for fixing it ljharb ! [12:36:12.0906] A doodle of something I might propose tomorrow for Stage 1: generic `Object.equiv` and `Object.diff` functions. https://gist.github.com/js-choi/b8b1a1c1388354d1b4384bea8a1fca0a [12:36:18.0333] * A doodle of something I might propose tomorrow for Stage 1: generic `Object.equiv` and `Object.diff` functions. https://gist.github.com/js-choi/b8b1a1c1388354d1b4384bea8a1fca0a [12:36:54.0955] It’s functionally a superset of https://github.com/tc39/proposal-array-equality. [12:36:56.0572] * It’s kind of a superset of https://github.com/tc39/proposals/blob/main/stage-1-proposals.md. [12:37:09.0719] * It’s functionally a superset of https://github.com/tc39/proposals/blob/main/stage-1-proposals.md. [12:38:14.0694] jschoi: I think that second link is not the correct link? [12:39:16.0290] * It’s functionally a superset of https://github.com/tc39/proposal-array-equality. [12:39:23.0742] Fixed, thanks. [12:49:45.0361] jschoi: It's a fun idea but for asking for stage 1 people mostly want a problem statement rather than a concrete possible solution, so you might consider presenting this as "i want to compare objects, ideally in a way where the objects can say how to compare themselves. stage 1?" and then after that discussion "also, having gotten stage 1, I want feedback on this direction I was considering, which I am not asking for stage advancement for" [12:50:38.0171] Yeah, agreed. [12:50:52.0198] Thanks for feedback. : ) [12:50:55.0124] though you could also consider seeing if the array equality champions would consider something like this in scope, in which case you wouldn't necessarily need to ask for stage 1 again for a separate thing [13:17:44.0239] > <@jschoi:matrix.org> A doodle of something I might propose tomorrow for Stage 1: generic `Object.equiv` and `Object.diff` functions. https://gist.github.com/js-choi/b8b1a1c1388354d1b4384bea8a1fca0a I've wanted to handle object equality for awhile (including use as keys in Map and Set). I created the `@esfx/equatable` package as a possible sketch (along with `@esfx/collections-hashmap` and `@esfx/collections-hashset`). https://esfx.js.org/#collections [13:34:14.0127] For what it’s worth, I think that diffing (not just testing with a boolean result) is a pretty common use case—every time you want to assert that two objects are equal, it is useful to be able to quickly see why are not the same. Imagine how many times you’ve added a temporary `console.log(thingA, thingYouExpectedToBeTheSameAsThingA)` line while debugging, but found that the things were very large and you had to painstakingly find the difference. I’ve even copied and pasted debugging output to text-diffing applications. Of course, assertion and test-runner libraries nowadays include such functionality for the same reasons. Anyways, any equality can be defined in terms of an empty a diff, so it’s a good opportunity to visit this. I’ll be talking with Hemanth H.M and ljharb about whether to tack this onto array-equality in another Matrix room. [13:34:29.0677] * For what it’s worth, I think that diffing (not just testing with a boolean result) is a pretty common use case—every time you want to assert that two objects are equal, it is useful to be able to quickly see why are not the same. Imagine how many times you’ve added a temporary `console.log(thingA, thingYouExpectedToBeTheSameAsThingA)` line while debugging, but found that the things were very large and you had to painstakingly find the difference. I’ve even copied and pasted debugging output to text-diffing applications. Of course, assertion and test-runner libraries nowadays include such functionality for the same reasons. Anyways, any equality can be defined in terms of an empty a diff, so it’s a good opportunity to visit this. I’ll be talking with Hemanth H.M and ljharb about whether to tack this onto array-equality in another Matrix room. [13:46:31.0105] for some prior art, see https://npmjs.com/is-equal, and import/require `is-equal/why`, you'll get a string explaining why they're different (but not a full diff) [13:53:02.0809] * For what it’s worth, I think that diffing (not just testing with a boolean result) is a pretty common use case—every time you want to assert that two objects are equal, it is useful to be able to quickly see why are not the same. Imagine how many times you’ve added a temporary `console.log(thingA, thingYouExpectedToBeTheSameAsThingA)` line while debugging, but found that the things were very large and you had to painstakingly find the difference. I’ve even copied and pasted debugging output to text-diffing applications. Of course, assertion and test-runner libraries nowadays include such functionality for the same reasons. Anyways, any equality can be defined in terms of an empty diff, so it’s a good opportunity to visit this. I’ll be talking with Hemanth H.M and ljharb about whether to tack this onto array-equality in another Matrix room. 2022-07-09 [02:19:19.0162] > <@bakkot:matrix.org> also Rust's methods are all on the Iterator trait I think I already commented that several times: Rust (and D) use iterator-like semantic, because these languages use value type semantic on iterator. So they don't suffer the reuse problem. And Rust have a very strong compiler which won't allow u reuse a iterator twice by default (you need to assign it to a separate var and with value type copy semantic, it give u a two iterator instances). Obviously JS do not have that merits. (Even I really hope we could have value type one day, I very doubt we can have value type semantic iterator in JS.) [02:20:32.0925] > <@ljharb:matrix.org> i'll fix the calendar, not sure where the current deadline event came from I guess it used the wrong timezone. :) [11:40:14.0795] > <@haxjs:matrix.org> I think I already commented that several times: Rust (and D) use iterator-like semantic, because these languages use value type semantic on iterator. So they don't suffer the reuse problem. And Rust have a very strong compiler which won't allow u reuse a iterator twice by default (you need to assign it to a separate var and with value type copy semantic, it give u a two iterator instances). Obviously JS do not have that merits. (Even I really hope we could have value type one day, I very doubt we can have value type semantic iterator in JS.) This is true, but the fundamental fact remains: in Rust the helpers are on the one-shot thing. Yes, in Rust the compiler will prevent you from making this particular mistake, whereas in JS you are more likely to get bit by it, so yes, there's a significant downside to using iterators that Rust does not have (though all the other languages I named do - nothing prevents you from trying to re-use a Java stream, e.g.). But the most important question is whether the helpers are usable and clear when used _correctly_, and on that question, the compiler checks are irrelevant. (And there's similar problems with accidentally re-using helpers on _iterables_ in other non-rust languages, for that matter - see e.g. the second half of https://stackoverflow.com/a/28513908, which discusses the downsides of C#'s IEnumerable design which were explicitly considered when designing Java's Streams. We're all jealous of Rust's compile-time checks but we still have to design a language which works without them.) [12:03:44.0851] I vaguely remember that someone a few years ago (was it Domenic Denicola?) trying to figure out in a GitHub Issue if we could ever have chained numeric comparisons like `x <= y < z`—and that sadly the person found that there was no way. Does anyone have a link to that thread? [14:59:21.0589] i just heard about the sf js meetup [14:59:31.0913] is there anything i need to do to be able to go to that [16:08:15.0219] snek: assuming you are talking about https://www.meetup.com/jsmeetup/events/287033071/, it says on https://github.com/tc39/Reflector/issues/437 that delegates are not required to RSVP 2022-07-10 [06:34:47.0624] I think Java Streams is ok, but we should note it is intentionally named as "Stream", to make it clear it's not Iterable/Iterator. If we follow Java design, we should also consider change iterator helpers to "Stream". Actually I think Emitter proposal is a very similar and more powerful Stream-like API, a good alternative to iterator helpers. [06:55:39.0655] bakkot: And the original question is whether number range() should be iterable/iterator, this is a separate question, not direct relate to the design choice of iterator helpers or iterable helpers or stream... Generally speaking I prefer iterable. I'm ok with iterator/stream version if it is make clear that's a iterator/stream (eg. naming it as `Iterator.integers()` or Java-like `IntStream.range()`). See https://github.com/tc39/proposal-Number.range/issues/57 [10:19:36.0523] Java's Streams happened after they'd already defined their `Iterator` interface and could no longer redefine it as a class; I don't think the naming there is that informative [10:19:51.0737] other languages like Scala and Rust did not make that choice [10:20:37.0863] anyway I agree with you about the particular question of `Number.range`, I'm mostly objecting to the assertion that every language which has an equivalent of iterator helpers has them for iterables rather than iterators [10:20:40.0640] * anyway I agree with you about the particular question of `Number.range`, I'm mostly objecting to the assertion that every language which has an equivalent of iterator helpers has them for iterables rather than iterators [11:08:23.0876] > <@bakkot:matrix.org> Java's Streams happened after they'd already defined their `Iterator` interface and could no longer redefine it as a class; I don't think the naming there is that informative Not sure what's the diff of interface/class in this case, Stream/IntStream is also interface in Java... [12:05:12.0168] Oh, yeah, ok [12:05:13.0730] Yeah I dunno [12:08:27.0917] possibly it's because java iterators support `.remove` and such [14:54:57.0092] bakkot, Michael Ficarra, nicolo-ribaudo: Can you check whether this Gist (about Array.fromAsync and AsyncIterator.prototype.toArray) matches your understanding? https://gist.github.com/js-choi/5b49b350995c5a44571be3d314e38162 [15:00:58.0141] * bakkot, Michael Ficarra, nicolo-ribaudo: Can you check whether this Gist (about Array.fromAsync and AsyncIterator.prototype.toArray) matches your understanding? I plan to post it in proposal-array-from-async#19 and refer to it from proposal-iterator-helpers#168. https://gist.github.com/js-choi/5b49b350995c5a44571be3d314e38162 I [15:02:09.0924] * bakkot, Michael Ficarra, nicolo-ribaudo: Can you check whether this Gist (about Array.fromAsync and AsyncIterator.prototype.toArray) matches your understanding? I plan to post it in proposal-array-from-async#19 and refer to it from proposal-iterator-helpers#168. https://gist.github.com/js-choi/5b49b350995c5a44571be3d314e38162 [15:06:43.0180] * bakkot, Michael Ficarra, nicolo-ribaudo: Can you check whether this Gist (about Array.fromAsync and AsyncIterator.prototype.toArray) matches your understanding? https://gist.github.com/js-choi/5b49b350995c5a44571be3d314e38162 (I plan to post it in proposal-array-from-async#19 and refer to it from proposal-iterator-helpers#168.) [15:12:04.0551] jschoi: lgtm [15:12:23.0002] though this line is a bit weird: > Bakkot points out that the “identity function” of Array.fromAsync does not have to be x => x. In actuality, it is async x => x. [15:12:33.0019] I don't know what "identity function" means there [15:12:34.0217] Yeah, I just revised it. Refresh the page? [15:12:49.0300] ah, sure [15:13:04.0153] I would change `the “identity function” of Array.fromAsync` to `the “default mapping function” of Array.fromAsync` [15:13:21.0501] Will do. Thanks for checking! [15:13:25.0812] or something like that. "identity function" is a property of values, not of functions like "fromAsync" [15:13:56.0879] Hopefully now we will have all our ducks in a row with regards to consistency between `Array.fromAsync`, iterator-helpers, and `for await`. [15:14:04.0326] * Hopefully now we will have all our ducks in a row with regards to consistency between `Array.fromAsync`, iterator-helpers, and `for await`. [15:16:15.0716] I believe so! [15:16:52.0017] I have an agenda item about similarly lining up `yield*` in async generators (https://github.com/tc39/ecma262/pull/2819) [15:16:56.0345] working on slides for it now 2022-07-11 [10:45:26.0060] does anyone who actually knows how `Set`s are implement know if it is possible to use the internal data structure to efficiently implement something like "order this list, which is a subset of the elements in some `Set`, according to the order the values in the list would be emitted when iterating the `Set`" [10:45:44.0922] "efficiently" meaning something like "with time proportional to the size of the list, not the size of the `Set`" [10:45:56.0024] I am guessing no but I have no idea what the actual implementation looks like [10:50:08.0758] what is the subset? [10:52:02.0161] uh [10:52:05.0789] like it's some elements of a set [10:52:48.0802] you have 1) a `Set` _x_ and 2) a list of some (but not necessarily all, and often much less than all) elements from _x_, which are not ordered according to the order in _x_ [10:52:59.0687] * you have 1) a `Set` _x_ and 2) a list of some elements from _x_, which are not ordered according to the order in _x_ [10:53:22.0530] and you want to sort the list according to the order of the elements in _x_ [10:53:55.0962] * you have 1) a `Set` _x_ and 2) a list of some (but not necessarily all, and often much less than all) elements from _x_, which are not ordered according to the order in _x_ [10:54:16.0489] the list is spec-internal, to be clear, so there's no side effects or anything happening during the process [11:01:31.0788] i do not understand the use case still, is there something concrete i can read? [11:05:50.0398] anyway maybe you can get some insight from https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables [11:06:01.0058] you don't understand the use case, or you don't understand the ask? [11:06:06.0100] i don't understand the use case [11:06:21.0695] is the sublist static, always same size? is it dynamic? [11:06:26.0119] what determines membership in the sublist? [11:06:58.0195] v8 continues to use roughly the same thing as described in jorendorff's wiki page there [11:07:16.0163] insertion order is simply the ascending order of the Entry array [11:07:23.0997] the use case is to get consistent order for `Set.prototype.intersection` - depending on which of `this` vs `other` is larger, you might be iterating `this` or `other`, and it would be nice if the order of the resulting set did not depend on which set was being iterated. [11:07:33.0150] i see [11:07:56.0146] and the obvious way to do that is to ensure the elements of the resulting set are ordered according to their order in `this` [11:08:31.0638] but if `this` is much larger than `other`, and performing said ordering takes time proportional to the size of `this` even when the intersection is small, that's bad [11:08:52.0064] you have two total orders, but how do you compose them into another total order? [11:09:02.0128] for intersection in particular, you don't need to [11:09:11.0203] ah it's intersection, right i see [11:09:28.0528] okay, i understand the use case now [11:09:46.0140] i have no idea how you do this efficiently in the current implementations of Set [11:10:15.0290] I haven't thought through all the other methods yet; it's possible this ordering wouldn't work for some of them. (others, like `union`, don't have this problem because the optimal algorithm does not produce a result whose order depends on the sizes of the input.) [11:10:27.0736] ok, alas. [11:10:39.0642] at the cost of either space or time everything is possible [11:10:46.0775] sure [11:11:31.0103] in this case, ISTM the shortest path would be to also store the index in the hash table `Entry` struct [11:11:40.0735] * in this case, ISTM the shortest path would be to also store the index in the hash table `Entry` struct [11:12:10.0503] (Ashley Claymore has suggested in https://github.com/tc39/proposal-set-methods/issues/70#issuecomment-1179692731 another option which adds a constant factor number of additional calls (not observable when it's a native Set) to get a deterministic if kind of strange order, which is my current leading alternative) [11:12:19.0607] you can then straightforwardly sort the list of indices pointed to by the elements in the intersection, and the indices in either of the source Sets would work [11:12:28.0445] but that's an extra int in every entry [11:12:30.0280] and that seems bad [11:12:35.0530] yeah [11:14:15.0802] well, wait a second now [11:14:49.0728] one of the properties of that particular implementation strategy of an ordered hash table is that the `Entry`s are allocated contiguously in an `Entry[]` array [11:15:11.0469] if you build an auxiliary list of the found `Entry`s in the intersection, you can presumably do address comparison [11:15:44.0895] i hope that falls out from most implementation languages' array allocation guarantees [11:15:57.0854] ooh, love me some pointer comparisons [11:16:24.0039] mind you i am not excited to recommend that in a non-normative note [11:16:29.0604] i don't know how you'd get UB to bite you, but it will [11:16:41.0118] the spec currently doesn't suggest any implementation strategy at all [11:16:57.0549] right, i'm just saying it seems very particular [11:16:58.0744] actually it might, I forget [11:17:01.0363] and a touch too clever [11:17:03.0630] yeah [11:17:26.0865] there are footguns there i'm worried about like [11:17:32.0903] what if the table is rehashed in the middle of performing the intersection [11:17:38.0689] is that even possible, i hope not but maybe [11:20:03.0910] okay so pointer comparison is my final answer and i'm sticking to it [11:20:07.0850] probably fine [11:20:49.0276] I would expect rehashing not to affect the `dataTable` itself, just the `chain` pointers within it, so I'd expect that to be fine [11:21:54.0667] yes true, so the entry addresses would be stable [11:36:41.0601] I am pretty sure you can replace the `Entry*` pointers in this document with indices into `dataTable` (both the `chain` pointer and the elements of the `hashTable` array), which makes it more obvious that this works and would work even languages which don't expose pointers [11:37:04.0331] yes [11:37:21.0455] but you don't want 2 loads [11:37:41.0820] unless you are using an inferior "safe" language [11:37:45.0547] sure [11:51:19.0225] What do we expect the order to be if the receiver is modified during the method call? [11:51:38.0450] as a user I don't have an expectation of what the order would be in that case [11:52:01.0441] so I'm just going to write down the thing which is easiest to implement, namely, elements are ordered according to their position in the list of entries when the algorithm queries them [11:52:13.0127] * so I'm just going to write down the thing which is easiest to implement, namely, elements are ordered according to their position in the list of entries when the algorithm queries them [11:58:38.0130] doing this sorting does add a `log(r)` factor overhead to theoretical performance (where `r` is the size of the result) in the case that `other` is smaller than `this`, but I expect that to be much cheaper than the overhead of doing more user-observable calls in most cases, so I'm not bothered about it [12:09:02.0462] i feel like that's fine [12:09:08.0088] logs aren't real [12:09:25.0218] that is also my belief [12:10:45.0767] though my beliefs might be incoherent because i believe constant factors are very real [12:14:29.0198] as a strict constructivist, I don't believe sets are real [12:14:36.0030] so this whole conversation has been moot [12:50:29.0914] Sets obviously aren't real, but Maps are. [12:50:58.0796] I assert that Maps aren’t real either, because Maps are not the actual territory. [12:51:07.0969] damn [13:47:41.0497] how do folks feel about Temporal updates as part of plenary? [13:48:28.0972] no offense meant to ptomato who's doing the important work, but i mostly don't understand or am in a position to have opinions about the normative updates [13:49:12.0013] We currently have a pattern that normative updates to Stage 3 proposals need consensus in committee; maybe the timebox should be shortened if people don't actually want to review them and just rubber-stamp? [13:49:21.0291] * no offense meant to ptomato who's doing the important work, but i mostly don't understand or am in a position to have opinions about the normative updates [13:49:49.0319] yes, that sounds good. if it is non-domain-specific, e.g. behaviors about options bags, then they should be presented [13:50:10.0405] but something like "we had to update this because the grammar upstream at ISO did this or that" is completely non-actionable for me [13:50:20.0046] maybe this can just be during the presentation, that the presenter can ask, "do people want me to go into these details?" [13:50:41.0396] that might make scheduling harder [13:50:45.0366] what would be unfortunate is if Temporal got held back because people said, "this doesn't have committee consensus yet; you can't ship this change" because we were trying to save time [13:51:26.0890] Stage 3 makes getting this all nailed down high priority for committee [13:51:58.0967] i'd like to lean on the temporal champions' judgment on if it's something that runs the risk of that failure mode [13:52:25.0821] the pattern for the past few meetings doesn't seem like a productive use of time to me [13:52:38.0370] > <@shuyuguo:matrix.org> i'd like to lean on the temporal champions' judgment on if it's something that runs the risk of that failure mode well, they put this on the agenda; you're the one pushing back [13:53:15.0861] i don't follow [13:53:30.0447] it's not the pattern today that we skip normative updates for stage 3 processes as you said [13:53:40.0778] I mean, if you want to defer to their judgement on whether to present it to committee... they communicated their judgement by putting this on the agenda [13:53:56.0549] i'm saying let's change the pattern, and the new pattern would be to lean on the temporal champions' judgment on what normative updates are worth presenting instead of every one [13:54:11.0371] oh, i wasn't under the impression they were already saying these are the list of updates worth presenting [13:54:15.0203] if so then i retract [13:54:19.0322] OK, sorry, I shouldn't speak for them; they can clarify [13:54:32.0327] and will just leave with the comment that i don't find them actionable and i zone out [13:56:56.0139] * it's not the pattern today that we skip normative updates for stage 3 proposals as you said [13:58:38.0262] I guess if we wanted to address this issue at a broader level we'd work on creating TGs that have the authority to make decisions on things. We could have a Temporal TG that can just decide fully on these changes without bothering plenary, and everyone who may have an opinion is expected to attend. I'd be in favor of this process change, but we haven't done it yet. [13:59:19.0109] i would also be in favor, and last time we brushed up against it there certainly were headwinds [13:59:23.0203] or concretely we'd probably give TG2 (402) this authority and task them with reviewing Temporal even though it's not in 402 [13:59:33.0760] * or concretely we'd probably give TG2 (402) this authority and task them with Temporal even though it's not in 402 [13:59:49.0838] * or concretely we'd probably give TG2 (402) this authority and task them with reviewing Temporal even though it's not in 402 [14:00:04.0759] agreed on TG2 [14:00:13.0851] chip has raised concerns about other domains as well [14:00:19.0507] regexps was it? [14:01:07.0930] so far we've said, those domains need to come back to plenary, their discussions are just advisory. Remember that I faced significant resistance when I just proposed that we meet in totally non-binding subgroups. [14:01:49.0673] yes, and similar resistance and concerns when incubator calls were proposed in their initial form [14:02:43.0841] well, I think Temporal is doing the right thing for this meeting, and we should probably keep pushing with giving subgroups the power to make decisions [14:02:54.0481] but, like, chartered subgroups, not random champion groups, IMO [14:03:13.0910] yes, agreed on chartered subgroups [14:03:58.0543] i mean i'd still like to reduce plenary time, but that's probably not a shared goal [14:04:11.0945] not reduce overall deliberation time over the set of all TC39 proposals mind you, but plenary time [14:04:31.0043] * not reduce overall deliberation time over the set of all TC39 proposals mind you, but plenary time [14:29:07.0449] Yeah I guess I'm neutral on that, or like it's not my top priority to reduce plenary time; top priority is to make good decisions inclusively, and plenary vs subgroups is more of a means to an end; all else being equal, good to use fewer person-hours, sure [16:29:26.0320] > <@shuyuguo:matrix.org> oh, i wasn't under the impression they were already saying these are the list of updates worth presenting is the question whether we have pre-filtered the updates that I put in the slides? [16:30:19.0311] (we haven't) [16:31:54.0180] ptomato: yeah, that was part of the question [16:32:36.0571] the other (to the broader committee) was do we feel comfortable leaning on the judgment of the Temporal champions to do the filtering, so only items of broad interest are presented, and we trust to rubber-stamp the rest [16:32:54.0297] well I asked this question previously and the answer was no [16:32:58.0878] since i don't know enough of the domain to, like, do anything other than rubberstamp [16:33:08.0017] oh too bad, i had forgotten [16:33:25.0633] yes, I'd love to skip the items that I know nobody cares about [16:33:51.0837] perhaps i can bring this up again to re-take the temperature [16:33:56.0392] what was the reasoning last time? [16:35:39.0968] I will look [16:36:13.0248] (FWIW, the status quo is better than the previous status quo, where the answer was "depends on who you ask") [16:39:55.0560] https://github.com/tc39/notes/blob/main/meetings/2022-01/jan-24.md#process-clarification - this is slightly different from what I remembered, good thing we have notes! I guess the "yes, we want this requirement" must have come from conversations before the plenary, the agenda item was only about making the unofficial requirement official [16:58:17.0039] yeah, i think there's a meaningful difference between "giving up plenary sign-off for normative changes" and "rubberstamp, trust domain experts to follow-up/review" [16:58:26.0986] the power still rests with plenary in the second case, and is more practical imo... [16:58:40.0963] * the power still rests with plenary in the second case, but one is more practical imo... [16:58:49.0417] * the power still rests with plenary in the second case, and is more practical imo... 2022-07-12 [17:04:47.0556] it does fit with the idea of TC39 as 'standing athwart history, yelling Stop' which seems to be one of the dominant mental models within committee [17:06:58.0969] (not one that I agree with, to be clear) [17:24:55.0930] i am not even interested in asking for a broad change currently, just for Temporal [17:25:24.0732] (This is the first time in years I’ve seen “athwart”. It is a great word.) [17:25:27.0606] * (This is the first time in years I’ve seen “athwart”. It is a great word.) [17:25:31.0238] i would invite folks with that mental model to contemplate if they would actually yell "stop" to a normative fix you present, ptomato [17:39:15.0196] > <@littledan:matrix.org> as a strict constructivist, I don't believe sets are real I believe some numbers are real, but not all of them. [17:41:45.0531] Or rather, most of them are not real. Pretty sure there’s proof to that effect. [17:44:32.0454] Sounds pretty complex to me. [17:45:55.0930] i... [17:53:34.0081] > <@jschoi:matrix.org> Sounds pretty complex to me. not necessarily [19:03:43.0324] tbh i think the requirement to present everything to plenary is actually a useful barrier; it means that all the things that get presented end up being obvious/boring [19:04:38.0618] and considering how many times it was brought up by littledan to demote `global` to stage 2 based on the name change, that nobody's considering Temporal to need demotion is a bit confusing [07:11:39.0049] idk maybe that was a mistake... ultimately I am still not really happy about the process global used. I think champions should be more transparent with the committee. [07:11:55.0332] so I'm a little wary of using that experience as an example that we should follow [07:13:40.0828] in the case of global, the whole proposal was only a name, and the stage 3 status was actively being used by multiple JS implementations/environments as a reason to ship exactly that (even after compat issues were discovered). So demoting was one way to send the signal that this wasn't the final state, though there would've been other ways. [07:14:01.0276] * in the case of global, the whole proposal was only a name, and the stage 3 status was actively being used by multiple JS implementations/environments as a reason to ship exactly that (even after compat issues were discussed). So demoting was one way to send the signal that this wasn't the final state, though there would've been other ways. [07:14:08.0124] * in the case of global, the whole proposal was only a name, and the stage 3 status was actively being used by multiple JS implementations/environments as a reason to ship exactly that (even after compat issues were discovered). So demoting was one way to send the signal that this wasn't the final state, though there would've been other ways. [07:15:36.0298] The tweaks being made to Temporal are much smaller in proportion to the size of the proposal. It is good that we aren't revisiting names, for example [08:03:05.0549] yes, i strongly agree the bar for demotion is something like "if it is no longer clear what needs to be implemented" and "if keeping stage 3 means shipping the wrong thing" [08:03:37.0217] temporal, while noisy, seems like all bugfixes to me, a bunch of which only (realistically) was going to be found after someone started implementing [08:03:47.0717] so demotion would be the exact wrong thing to do here [08:04:32.0256] for something of temporal's size, the bugfix noise is pretty unavoidable [08:14:18.0047] Procedurally, my understanding that the requirement for demotion, like promotion, is consensus. [08:23:22.0647] mine as well [08:23:55.0864] we achieved that with global, and with static class features, so things were above board, but it's possible to object to demotion, I think [08:25:32.0029] yeah, i'm explaining the expectation of the bar i'd be judging proposals by if something came up for demotion [08:25:46.0353] yeah, I agree with your bar [08:25:54.0488] that this is what delegates should keep in mind [08:26:10.0941] maybe it's time for a how-we-work PR? [11:42:35.0461] also Temporal is the size of a new spec unto itself so it's really not fair to compare it to a run-of-the-mill small proposal [12:07:45.0778] rkirsling: that's a really good point! What makes Temporal hard is that the proposal is a family of related types rather than individual types or functions that can be added incrementally and individually. It's hard to imagine any other problem domain being added to the language that would require such a large surface area, with the possible exception of file I/O if that's ever added to the standard library. [12:07:49.0599] i totally agree demotion requires the same consensus advancement does, and that temporal isn't really stage 2 (nor was global at the time), but also neither is/was truly stage 3. i wish we had some kind of stage 3.5 [12:07:57.0834] * i totally agree demotion requires the same consensus advancement does, and that temporal isn't really stage 2 (nor was global at the time), but also neither is/wa truly stage 3. i wish we had some kind of stage 3.5 [12:07:59.0535] * i totally agree demotion requires the same consensus advancement does, and that temporal isn't really stage 2 (nor was global at the time), but also neither is/was truly stage 3. i wish we had some kind of stage 3.5 [12:10:24.0788] yeah, we talked about something after stage 3 in this room; I think it'd be good to bring that to committee at some point for further discussion. We agreed on a lot of things (e.g., that by default, something is "shippable" when promoted to Stage 3 unless otherwise specified) and we identified a point of disagreement whether the champion can just unilaterally document whether something is "shippable", or whether this is subject to review/consensus/objections by the rest of the committee. [12:21:44.0401] Stenography support may be coming to the next plenary! If you get a chance, editing the glossary will help the captioner. https://github.com/tc39/how-we-work/blob/main/terminology.md [12:49:22.0216] yeah, i'm positive on a stage 3.5 with relatively little oversight [12:49:50.0953] i.e. a little more formalism than what's happening today which is like a browser saying "hey btw let's not ship this until we iron out this issue" and everyone else nodding [14:21:39.0124] Would Stage 3.5 occur on all proposals or just “special” ones similar to Temporal? [14:22:59.0808] The idea is to have a column in the proposals repo which is whether something is "shippable" (or maybe inversely, whether it has open questions which block shipping). In the normal course, the shippable bit is set at the same time as going to Stage 3. All proposals would have this bit, not just ones which are un-shippable. [14:23:09.0302] * The idea is to have a column in the proposals repo which is whether something is "shippable" (or maybe inversely, whether it has open questions which block shipping). In the normal course, the shippable bit is set at the same time as going to Stage 3. All proposals would have this bit, not just ones which are un-shippable. [14:23:49.0166] there would be no real contract associated with the shippable bit; it's just a piece of advice from the champion to implementers and everyone else, in my (and Shu's, maybe) vision of how this works [14:24:12.0275] there's like, a social contract, in the world [14:24:16.0512] there's no formal contract in committee [14:24:16.0732] right [14:24:45.0716] brb preparing a docusign [14:24:59.0087] of the social contract [14:25:15.0956] can you imagine, changing consensus process straight to docusign [14:25:19.0369] 45 counterparties [14:25:44.0650] Would tweaks be needed to the current definition of Stage 3 saying, “The solution is complete and no further work is possible without implementation experience, significant usage and external feedback”? [14:26:17.0382] I wasn't picturing any stage process definition tweaks as part of this [14:26:57.0279] I think we could clarify the process wording but that's a big separate thing [14:27:12.0921] * I wasn't picturing any stage process definition tweaks as part of this [14:27:15.0272] I suppose the difference between “the solution is complete and [needs] implementation experience” (Stage 3 without the “shippable” checkmark) and “this is ready for serious implementation” (Stage 3 with the “shippable” checkmark) seems a bit subtle. [14:27:33.0643] I’m imagining what it means in general to be at Stage 3 but to not have the shippable checkmark. [14:27:34.0168] we've had way too many arguments about this; I don't want to discuss it right now [14:27:41.0843] sorry [14:27:46.0472] Ah, okay, sounds good; don’t let me open the Pandora box. [14:30:42.0260] I documented what makes sense to do at each stage in https://github.com/tc39/how-we-work/blob/main/champion.md#moving-through-the-stages-in-committee [14:31:35.0886] I think we should move towards pointing people to how-we-work more frequently, and the formal process document doesn't need to be how we explain the process in practice to people all the time (since it just leaves so many things out which are important to understand) [14:31:58.0060] it's too hard to maintain how-to documentation in a consensus-seeking way [14:40:32.0425] > <@littledan:matrix.org> The idea is to have a column in the proposals repo which is whether something is "shippable" (or maybe inversely, whether it has open questions which block shipping). In the normal course, the shippable bit is set at the same time as going to Stage 3. All proposals would have this bit, not just ones which are un-shippable. yeah I was thinking this too; some notion of a "bit" makes more sense than asking whether a tiny feature is "going right to 3.5" [14:49:01.0912] i'm most excited about how i can apply my newly found, most likely incorrect knowledge of contract law thanks to Elon's antics to tc39 [14:49:11.0205] * i'm most excited about how i can apply my newly found, most likely incorrect knowledge of contract law thanks to Elon's antics to tc39 [14:51:17.0871] wait, is our alternate copyright policy not accompanied by a matching alternative patent policy saying the same thing but for patents? [14:51:26.0469] maybe it's not possible to do that, I dunno [14:52:13.0201] i did not know there was an analogue for patents [14:57:22.0582] ah probably it's not important. Both the Ecma and WHATWG policy limits the patent grant to current and future implementations of the standard (which might imply not forks). Probably broadening it would require bringing in lawyers and isn't necessary in practice [14:58:05.0635] sorry for the noise [14:58:34.0426] > <@shuyuguo:matrix.org> i'm most excited about how i can apply my newly found, most likely incorrect knowledge of contract law thanks to Elon's antics to tc39 misparsed this with [Elon's antics to TC39] and got worried for a sec [14:59:07.0009] #longrangedependencyproblems [15:36:13.0666] does anybody else find terminology.md hard to read due to skipping second-level headings [15:36:26.0723] er [15:36:31.0896] I mean https://github.com/tc39/how-we-work/blob/main/terminology.md of course [15:37:11.0369] third-level headings are not prominent enough and would require \
s for delineation...or y'know, we could just use second-level headings [15:38:59.0202] * third-level headings are not prominent enough and would require \
s for delineation...or y'know, we could just use second-level headings [15:42:41.0724] (I wonder if GH's stylesheet changed somewhere along the line; I don't remember being so bothered when editing this document in the past) [16:19:33.0653] https://github.com/tc39/how-we-work/pull/109 [16:37:49.0913] reviewing temporal patches is just like [16:37:53.0417] date time handling is so cursed [16:50:23.0564] This champion.md document is great. To be honest…I had never seen it before. I don’t know why; I feel like I should have noticed it when I looked through how-we-work…And, yes, I had always relied on the process document as my primary reference on what to do at each stage. [16:50:43.0885] > <@littledan:matrix.org> I think we should move towards pointing people to how-we-work more frequently, and the formal process document doesn't need to be how we explain the process in practice to people all the time (since it just leaves so many things out which are important to understand) * This champion.md document is great. To be honest…I had never seen it before. I don’t know why; I feel like I should have noticed it when I looked through how-we-work…And, yes, I had always relied on the process document as my primary reference on what to do at each stage. 2022-07-13 [10:40:19.0331] > <@rkirsling:matrix.org> https://github.com/tc39/how-we-work/pull/109 can I get an approval here? would like to merge before defining stuff [15:19:53.0228] restructured so that the page is cleanly divided into Glossary and Contributing: https://github.com/tc39/how-we-work/pull/110 2022-07-14 [09:17:55.0940] https://github.com/tc39/how-we-work/pull/111 [09:18:24.0458] PR to fix a bunch of markdown issues and move the template code to a code block [09:19:10.0260] next one I will have will fix the alpha order of terms (and add the alpha order requirement in the contribution section) [09:53:02.0084] if markdownlint is actually good (I have not used it), we should maybe set it up in CI? [10:15:43.0160] yeah this was the first I'd heard of it but it seems wise [11:02:57.0616] I've been using it for 6 years or so. it's great, but I've never bothered to add it to any CI because it's md and not quite "code", but that's a good idea [11:07:31.0971] Missed opportunity for “Lint, M.D.” pun. [11:22:23.0644] +1 for adding it to CI; i use `evalmd` in many of my projects in CI to ensure that code examples execute successfully, and linting markdown also seems useful [11:47:14.0794] I wouldn't mind setting it up, but I lack the requisite permissions on the repo [11:48:00.0161] you should be able to just send a PR adding a github action? I don't think you need permissions beyond that [11:49:31.0627] ah, true. I was thinking more about configuring status checks, etc [12:02:17.0622] i can configure them once it's merged [13:40:53.0994] https://github.com/tc39/how-we-work/runs/7347701399?check_suite_focus=true [13:41:32.0105] linting github action added. see test result ☝️ [13:41:38.0974] * linting github action added. see test result ☝️ 2022-07-17 [14:51:35.0747] I’m looking at simplifying Ecma262’s definition of Array.from to use %Array.prototype.values%, like how https://tc39.es/proposal-array-from-async/#sec-array.fromAsync uses %Array.prototype.values%. As far as I can tell, this should be editorial, but, if so, would it still deserve to be presented as a 2022-09 plenary agenda item? [15:21:04.0287] jschoi: anything strictly editorial does not need to be presented in plenary [15:21:54.0541] but, `Array.prototype.values` produces an iterator which uses the _current_ value of `%ArrayIteratorPrototype%.next`, which is not what `Array.from` does [15:22:18.0816] so it's not a totally straightforward refactoring [15:23:46.0578] This might be a problem for the currently proposed Array.fromAsync algorithm too, then. [15:24:03.0110] * This might be a problem for the currently proposed Array.fromAsync algorithm too, then. [15:39:09.0685] yup 2022-07-18 [12:04:40.0039] could someone with access to the TC39 calendar please delete the event today? [12:56:27.0802] > <@usharma:igalia.com> could someone with access to the TC39 calendar please delete the event today? yep, on it [12:56:49.0515] actually wait, i deleted that awhile ago [12:56:54.0330] it’s not there now [12:57:15.0667] weird, must be my client then. [12:57:19.0284] if you’re not using Google calendar tho the deletion might not propagate on a recurring event [12:57:29.0201] I see [14:29:12.0282] ooh a set methods discussion [15:08:16.0519] Hey all, if anyone is in town (San Francisco) for plenary and would like to meet for dinner this evening, please say. There's a bunch of us (me, RobinR, AshleyC, LittleDan, RobertPamely, maybe AndrewP) already here and so we'll find somewhere. All are welcome. [15:09:19.0644] interesting [15:10:10.0964] I'm down in San Mateo so I'd need to take a train up there but how can I say no? :D [15:20:19.0766] * Hey all, if anyone is in town (San Francisco) for plenary and would like to meet for dinner this evening, please say. There's a bunch of us (me, RobinR, AshleyC, LittleDan, RobertPamely) already here and so we'll find somewhere. All are welcome. [16:57:15.0437] The draft schedule (never a promise, purely a guide) is now posted on the Reflector: https://github.com/tc39/Reflector/issues/437 Please do **not** post the URL here because this channel is public and logged. 2022-07-19 [17:11:55.0529] Rob Palmer: you have my 5m item scheduled on the day i can't attend [17:20:07.0498] Fixed [17:26:15.0281] ty [17:44:30.0577] Retweets on the Community Event invitation are appreciated: https://twitter.com/TC39/status/1549192175891652608 [17:50:05.0155] A headsup for tomorrow's plenary meeting: We are going to use Google Meet for dial-in (instead of Jitsi) We will open the call at 09:30 so folk can test their AV setup. https://github.com/tc39/Reflector/issues/437#issuecomment-1188456766 [17:51:03.0686] If anyone is attending plenary in-person in SF tomorrow, please ensure you have read the entirety of the Reflector main post, otherwise you risk getting denied entry. https://github.com/tc39/Reflector/issues/437#issuecomment-1188456766 [17:59:26.0326] Also, breakfast is provided. So you have an incentive to arrive at 09:20. [20:13:58.0717] Anyone here driving through or around Fremont tomorrow? 🤓 [08:35:26.0106] Hello all, the meeting begins in 90 minutes. The signup sheet is now linked from [the Reflector](https://github.com/tc39/Reflector/issues/437) which you can use to get the Google Meet URL. The Google Meet call will be available for entry from ~45 mins before the meeting onward. If you are attending in person please remember your photo ID, proof of vaccination, and mask. [09:02:39.0734] Rob Palmer: The draft schedule has a video call link. You should probably remove it. [09:19:30.0809] are we meant to come to the Folsom st door? [09:20:44.0008] * which lobby are we meant to come to? [09:21:25.0275] I'm at the Spear Lobby Visitor Entrance [09:28:00.0491] You are correct. [09:32:54.0412] ok, we have 8 people in thephysical room [09:41:45.0863] are people eating elsewhere or something? [09:42:12.0787] oh my gosh, in person meetings! [09:46:07.0474] it's very confusing; Dan came in here and yelled at me and then immediately left and it's like [09:46:31.0034] I don't why I'm the only one eating here but I'm eating so geez [09:49:12.0159] All, Google Meet does not let you change your name to the desired form ` ()` so please use Incognito/Private browsing mode - then it will allow you [09:54:27.0016] I find the video conf section of the doc confusing [09:54:32.0220] * I find the video conf section of the doc confusing [09:54:53.0235] is `https://meetings.igalia.com/tc39plenary` accurate? is that the google meet meeting? is jitsi/8x8 used or not? [09:55:31.0447] To get the link to the gmeet you'll need to fill in the sign in form [09:55:36.0859] no, check the reflector [09:55:44.0450] this is #437 btw .. in the reflector [09:55:53.0807] also please delete links from this channel, it is logged publicly [09:56:11.0949] * also please delete links from this channel, it is logged publicly [09:56:30.0691] oh.. the issue has been updated, I'm looking at an email from 8 June.. 🤦 [09:56:38.0757] easily done! [10:01:56.0982] The meeting is now starting [10:01:58.0395] yeah so that clarification would've been helpful much earlier [10:02:13.0794] so that I wouldn't've had to be yelled at [10:02:20.0215] I didn't appreciate that [10:03:40.0976] is somebody speaking? I have no audio [10:04:29.0397] Others are getting audio ok (we got thumbs up) [10:04:59.0448] I did the audio test in meet and it plays fine but I'm getting no call audio [10:05:04.0066] I will try reconnecting [10:05:25.0001] rejoining worked [10:05:25.0944] strange [10:06:08.0771] computers /shrug [10:09:17.0678] Roughly how many people are in the room? [10:09:28.0020] 20ish [10:12:19.0279] the microphone seems highly directional [10:22:34.0276] oh wow, I forgot about introductions! [10:25:29.0606] congrats rkirsling on the big move! [10:25:40.0419] thank you!! [10:27:14.0659] 🦆 [10:28:36.0456] congrats nicolo-ribaudo on the upgrade :D [10:30:42.0575] Congrats on the GPU Yulia [10:32:10.0697] important question: what games are you putting on that GPU? [10:32:24.0756] Sorry, I should have posted in tes [10:32:30.0431] TDZ* [10:33:35.0460] > <@rick.button:matrix.org> important question: what games are you putting on that GPU? Factorio :) [10:35:04.0927] gaming? on a gpu? i thought those were for generating funny pictures [10:35:14.0380] > <@lucacasonato:matrix.org> Factorio :) satisfactory [10:35:24.0972] *waggles eyebrows* [10:35:33.0981] *in the direction of tdz* [10:37:45.0032] there are 21 people here in the room in SF [10:38:40.0128] TCQ agenda/speaker not working [10:39:10.0051] thanks [10:39:58.0432] thanks, Chris - i fixed it now [10:46:21.0814] what was the deal with the "nice" thing [10:46:58.0266] we have ugly pdfs i hear [10:47:51.0121] the current editors have not prioritized the pdfs, it is true [10:48:09.0959] another way to say it is, the only people who care about the PDF quality haven't prioritized it until now [10:48:15.0453] I guess I was just curious what specifically Allen did [10:49:46.0621] rkirsling: https://twitter.com/awbjs/status/1548072759741124609 [10:50:02.0123] attending a UTC+1 meeting remotely from the US is going to suuuuuuuck [10:50:18.0402] thanks! I missed that thread [10:50:38.0097] You should expect a presentation from the inclusion group and/or chairs about the NVC funding issue in a future meeting. We just didn't have time to prepare such a presentation before this meeting. [10:51:04.0943] 6pm-1am in PT isn't too bad, but in CT that'd be rough [10:51:32.0463] I'd prefer that Istvan coordinate on these presentations a bit more; if he has questions, he can ask those involved. [10:52:40.0922] those points really do seem to suggest a fundamental misunderstanding of the purpose of the training 😕 [10:52:49.0018] > <@ljharb:matrix.org> 6pm-1am in PT isn't too bad, but in CT that'd be rough I think you're doing the conversion wrong. A 10:00A meeting in Norway starts at 2:00A for me, 1:00A for you [10:53:57.0726] time to exercise "letting go" [10:54:07.0540] not sure i wanna have a 5 hour meeting at 1am [10:54:22.0298] didn't we have one earlier this year? [10:54:23.0440] or last year [10:54:25.0064] or the one before [10:54:29.0805] yeah and it was not fun [10:54:31.0547] (for people in PT) [10:54:33.0970] We have a number of delegates calling in from Asia at this point, so it seems only fair to give them a break for once [10:54:40.0924] or twice [10:55:28.0010] how about we compromise and have all meetings in my personal timezone wherever i am [10:57:14.0649] According to google it takes 335 days to walk around the globe, you could start walking and the meetings would be mostly equally distributed in one year [10:57:27.0267] > <@devsnek:matrix.org> how about we compromise and have all meetings in my personal timezone wherever i am * According to google it takes 335 days to walk around the globe, you could start walking and the meetings would be mostly equally distributed in one year [10:57:32.0237] ecma 262 is on summer mode lol [10:57:53.0276] oh i was thinking tokyo [10:57:57.0128] yeah norway's going to be very rough [10:57:59.0240] * yeah norway's going to be very rough [10:58:05.0167] > <@nicolo-ribaudo:matrix.org> According to google it takes 335 days to walk around the globe, you could start walking and the meetings would be mostly equally distributed in one year much faster if you start at one of the poles [10:58:48.0435] lol [11:00:02.0821] Korea Advanced Institute of Science & Technology (KAIST) [11:00:13.0487] neat [11:00:20.0318] Robin Ricard: ^ [11:00:33.0417] see https://github.com/es-meta/esmeta [11:02:00.0064] has the bot stopped? [11:02:01.0941] The list of teams: https://github.com/orgs/tc39/teams/delegates/teams [11:02:09.0727] nvm [11:02:14.0961] * The list of teams: https://github.com/orgs/tc39/teams/delegates/teams [11:02:29.0363] Github teams for member orgs: https://github.com/orgs/tc39/teams/delegates/teams [11:02:57.0360] btw if you are presenting this meeting, are on a mac, and have not given your slideshow software (e.g. chrome) permission to present, you may want to do that now [11:03:07.0169] Ah, just https://github.com/orgs/tc39/teams/ didn't list it. [11:04:54.0058] Ah, just https://github.com/orgs/tc39/teams/ didn't list it. [11:06:27.0140] it's underneath "delegates" which is underneath "eligible meeting participants" [11:09:18.0700] thats very useful to have the version [11:09:22.0421] * thats very useful to have the version [11:09:35.0616] sffc: You should see if it's feasible to generate polyfills using KAIST's esmeta [11:10:04.0854] they are apparently able to generate a reference implementation for most of 262, so 402 should be a breeze [11:10:20.0394] sorry, didn't mean to ping while you were presenting [11:12:00.0340] most of 402 is locale stuff, but I guess it's possible you could wire up something with ICU [11:13:23.0604] are the polyfills not bring-your-own-ICU-data? [11:13:29.0966] they bundle that data? [11:13:35.0378] ljharb: Bill Budge is no longer at Google [11:14:41.0929] https://github.com/tc39/Admin-and-Business/issues/259 [11:15:17.0745] ljharb: do CoC updates go in the notes? I forget [11:15:53.0849] yeah, it's fine, anything that can't go in the notes, we can't tell plenary either [11:22:17.0096] TA has subarray, which is the thing I want [11:22:35.0616] i never want non-contiguous subarrays of a TA [11:24:36.0966] note that TAs also do not have flatmap [11:24:42.0659] 'cause like [11:24:44.0960] why do you want that [11:24:49.0454] flatmap is also non-mutating, though, so it's possible in the same sense as toSpliced [11:24:58.0182] * flatmap is also non-mutating, though, so it's possible in the same sense as toSpliced [11:25:17.0836] yeah [11:25:30.0795] the ES6-era thing of just having all the Array stuff on TAs is just not the right call [11:25:38.0390] why are you sorting your bytes?? [11:25:46.0385] lol i just posted that tweet in tdz shu [11:25:51.0662] * lol i just posted that tweet in tdz shu [11:26:13.0940] * the ES6-era thing of just having all the Array stuff on TAs is just not the right call [11:26:15.0941] people do run interesting algorithms on TA data, but very rarely are they written in terms of high level operations like flatmap [11:26:20.0733] wait, like, if it exists, it would have to be called toSpliced, no? since that what the operation is (I'm for excluding it, but yeah) [11:26:24.0092] > <@michaelficarra:matrix.org> sffc: You should see if it's feasible to generate polyfills using KAIST's esmeta Could you suggest this in https://github.com/tc39/ecma402/issues/700 ? [11:26:36.0287] * wait, like, if it exists, it would have to be called toSpliced, no? since that what the operation is (I'm for excluding it, but yeah) [11:26:41.0031] do i want typedarray to be learnable [11:27:11.0289] i think typedarray should be learnable, its not one of those evil features like atomics [11:27:25.0924] detachment is arguably evil [11:27:27.0769] lol [11:27:39.0619] once we have resizing [11:27:42.0811] 🙏 [11:31:23.0191] the name is fine by me [11:31:33.0159] OK, so, how do we draw a conclusion here? [11:31:33.0744] i mean splice is already a gross name but it exists, having another name is worse [11:31:47.0112] Do people feel convinced by the champion's arguments? [11:31:58.0936] temperature check? [11:32:58.0802] > <@bakkot:matrix.org> i mean splice is already a gross name but it exists, having another name is worse yes but we always have the option that do not add "toSpliced" method at all, so we won't spread the gross name more. [11:33:34.0950] yeah but you need it on tuples [11:33:42.0615] you really need it on tuples [11:34:05.0988] is there any interest in moving just `TypedArray.prototype.toSpliced` to a follow on? [11:34:13.0149] to resolve this? [11:34:17.0742] ehh I think this could be resolved now [11:34:31.0186] littledan: i'd rather we follow res judicata if there is any sentiment to keep toSpliced, we keep it, because it's already stage 3. bar to make stage 3 normative changes should be high [11:34:44.0495] to me TAs are just special [11:35:04.0113] yeah [11:35:12.0865] res judicata > An issue that has already been decided by another court, and therefore must be dismissed. [11:35:28.0425] tc39 common law [11:35:28.0598] oh i guess i used it incorrectly then [11:35:34.0975] we should only add methods on TAs when they actually make sense for TAs specifically [11:35:37.0117] i meant more like we decided earlier [11:35:58.0889] > <@bakkot:matrix.org> yeah but you need it on tuples I suggested a different api: https://github.com/tc39/proposal-change-array-by-copy/issues/80 [11:37:00.0716] What each emoji mean? [11:37:56.0466] :+1: = you like toSplice for TA 😕 = you don't like toSplice for TA [11:38:57.0636] I don't know which one I should choose, because I dislike toSpliced at all, but if we must have it, it seems TA should also have it... [11:39:07.0026] well, unconvinced is a pretty good description of my feling [11:43:51.0997] I'll be off for 15 min [11:44:01.0359] dminor can field anything for mozilla [11:46:23.0724] ah yes, the saddest of all keys [11:46:27.0612] * ~~ah yes, the saddest of all keys~~ [11:46:34.0823] * -ah yes, the saddest of all keys- [11:46:50.0143] (for crying out loud, how do I strikethrough, Matrix) [11:47:01.0803] `` [11:47:09.0626] like this [11:47:18.0785] * ah yes, the saddest of all keys [11:48:24.0551] its totally up to each client [11:49:02.0902] https://github.com/tc39/test262/pull/3525 [11:52:14.0531] as the maintainer of engine262 i support this change lol [11:53:27.0150] snek: congratulations on your faithful implementation which is now incorrect [11:53:38.0883] such is life [11:56:02.0656] just to be clear we're back in 65 minutes? [11:56:05.0774] 64 now [11:56:14.0029] yes [11:56:15.0375] corect [13:03:02.0338] Have we retrieved all delegates from the patio? I believe that’s the last place I saw Peter Hoddie during lunch. [13:04:57.0362] we're on time, but in the future maybe we could call out for delegates still busy with lunch? [13:06:08.0404] Sorry for our delay! [13:06:16.0684] * Have we retrieved all delegates from the patio? I believe that’s the last place I saw Peter Hoddie during lunch. [13:15:34.0907] I feel `parseImmutable` should be `parsePrimitive` ? [13:15:51.0827] HE Shi-Jun: Can you say why? [13:16:54.0297] immutable is a little bit broad word, it could be immutable object. and it also make us impossible to make tuple/record become mutable value type (just like swift) [13:17:07.0771] in the future [13:17:56.0113] I feel fine committing to making record/tuple not becoming a mutable value type like in Swift; to avoid making way too many copies, Swift depends on compiler optimizations that would be infeasible for JS [13:19:43.0878] I think we need more investigation on value type, at least we shouldn't add constraint in current status by naming it "immutable" [13:21:04.0059] Swift use CoW optimization, it seems js engines still can use such tech, for example, I believe JavaScriptCore use CoW heavily? [13:21:39.0852] Regardless of compiler optimizations, immutability has been one of the core goals of this proposal since the beginning [13:22:14.0669] I think this proposal loses a lot of its value if we move away from immutability. [13:23:01.0931] "one time", except for Array [13:23:16.0324] > <@nicolo-ribaudo:matrix.org> Regardless of compiler optimizations, immutability has been one of the core goals of this proposal since the beginning Value type do not need to be "immutable". I think we start with immutable, because in the languages without value type, we have to use immutable objects. But we shouldn't mix the concepts. [13:24:01.0392] > <@littledan:matrix.org> I feel fine committing to making record/tuple not becoming a mutable value type like in Swift; to avoid making way too many copies, Swift depends on compiler optimizations that would be infeasible for JS HE Shi-Jun: If you have an idea for how to get past this issue, I'd be interested to hear it. [13:24:22.0963] `__proto__` not being allowed is unfortunate but understandable [13:24:47.0466] > <@littledan:matrix.org> HE Shi-Jun: If you have an idea for how to get past this issue, I'd be interested to hear it. What issue? [13:25:20.0099] the issue where, to use a Swift-like approach for CoW immutable things without tons of copies, you need to determine when there is *not* a reference to the original value, which is fundamentally hard in JS [13:25:49.0904] (e.g., the environment record may reference the object, and so you need to prove that this reference is dead, which is easier to do in Swift than in JS) [13:27:36.0543] also the runtime version of CoW depends on reference counting, also easier in Swift [13:30:46.0683] I'm not sure I fully understand your question. IMO, the problem is always there, the idea of "mutable" tupe/record could be easily think as a syntax sugar of creating a new tuple/record. For example, `let x = #[1]; x[0]++` could be think as sugar of `x = #[x[0]+1]` [13:31:29.0216] ljharb: i feel like the symbol protocol _is_ the icky hardcoded special case [13:31:40.0761] it's only there for historical reasons [13:31:49.0523] it could have been an internal slot that HTML sets too tho [13:33:47.0426] How do I change my company on TCQ? [13:33:51.0774] we went this route because ES6 specifically was trying to make all special behavior explicable in terms of user-exposed mechanisms [13:33:55.0760] this was a mistake [13:33:58.0521] (IMO) [13:34:02.0972] > <@nicolo-ribaudo:matrix.org> How do I change my company on TCQ? by changing it on github [13:34:07.0363] it would be nice if any implementors could share their view here. concat spreadable being a bailout condition in multiple engines seems to speak very accutely to the fact that no one is using this or really cares about it [13:34:39.0468] * it would be nice if any implementors could share their view here. concat spreadable being a bailout condition in multiple engines seems to speak very accutely to the fact that no one is using this or really cares about it [13:34:43.0198] i have not heard any contrary evidence that it's some widely useful protocol [13:34:54.0156] so it remains a protector in V8 with the cliff [13:35:21.0752] note that this isn't a JIT cliff but rather a switch among multiple implementations of the function, the slow version and the fast one [13:35:25.0756] Ashley Claymore: That's exactly what I meant, thank you! [13:35:41.0877] littledan: it's not just that in V8, it's one of those protector things [13:35:49.0551] there's a protector on prototype lookups of @@isConcatSpreadable [13:35:57.0721] to be fair all my personal use cases are or will be around concat-spreading arrays and tuples only, not generic spreadable objects. but it seems like a weird deviation from an established protocol. [13:36:07.0843] right, and the protector switches you globally into the slow version [13:36:13.0666] right [13:36:17.0249] but regardless of JIT stage [13:36:21.0686] correct [13:36:21.0853] the thing that interests me is that they consider it acceptable to treat it as a slow path, implying to me that it really has no usage in practice and we should not bother trying to bring it forward. [13:36:27.0975] * the thing that interests me is that they consider it acceptable to treat it as a slow path, implying to me that it really has no usage in practice and we should not bother trying to bring it forward. [13:38:13.0734] > <@littledan:matrix.org> also the runtime version of CoW depends on reference counting, also easier in Swift So the CoW optimizations are similar. If runtime know there is no `x` shared, they could just modify the value of `x`, if it's shared, it just copy `x` and modify on new `x`. Of coz engines could choose always copy `x`, do not need ref counting. [13:38:13.0777] I'll move my queue items to the issue tracker to save time [13:39:15.0257] to be clear, these exotic wrappers only come up when you invoke a method (presumably with `.call`) in sloppy code with the record or tuple as its `this` [13:39:28.0210] it's a very narrow case and I don't much care about sloppy-mode code [13:39:37.0748] (if my understanding is wrong please correct me) [13:39:50.0345] what's the problem with hard coding things? [13:40:27.0146] > <@bakkot:matrix.org> (if my understanding is wrong please correct me) this sounds correct to me [13:40:27.0648] rickbutton: I don't think Jordan's concerned about the verbosity of the spec [13:41:00.0394] oh thats what I interpreted it as (in addition to the JS-side problems) [13:41:05.0013] bakkot: they also come up when doing `Object(record)` explicitly, right? [13:41:35.0954] sure I guess [13:42:02.0632] I also don't much care about that code [13:42:51.0199] strings are containers of characters [13:43:05.0665] that's a loaded sentence [13:43:08.0810] strings are containers of strings [13:43:10.0873] so much so that you can make something that looks a lot like a string with a tuple [13:43:17.0628] numbers are containers of bits [13:43:19.0754] oh this isn't tdz [13:43:33.0189] yeah I don't think these should pass an `isRecord` check [13:43:34.0774] * oh this isn't tdz [13:43:37.0390] * yeah I don't think these should pass an `isRecord` check [13:44:06.0180] in fact it is not totally clear to me why (or if) this is different from just making a new, regular, frozen object with properties and prototype being copied [13:44:19.0369] I guess invoking methods on tuples works, is the main difference? [13:44:30.0876] but you can have the tuple methods check for the special wrapper [13:44:41.0960] r&t have new `typeof` values right [13:44:47.0090] yes [13:45:04.0042] yeah i feel very unmotivated about the whole object wrapper situation lol [13:45:19.0134] > <@devsnek:matrix.org> yeah i feel very unmotivated about the whole object wrapper situation lol I _hate_ object wrappers [13:45:25.0309] you need _some_ sort of wrapper for sloppy code here [13:45:27.0604] well [13:45:38.0455] I guess you technically don't but you probably should [13:45:47.0305] I don't think the word "axiom" makes much sense here [13:45:52.0883] more like "true statement" [13:46:12.0091] i feel like Object(record) should make a copy of the record with all the keys [13:46:14.0673] that seems better [13:46:16.0872] > <@bakkot:matrix.org> I guess you technically don't but you probably should We considered hiding wrappers for R&T and it's possible, but it would be different from what every other primitive does [13:46:22.0720] that's like being a wrapper [13:46:29.0226] nicolo-ribaudo: that's fine by me [13:46:34.0756] wrapper existing and wrapper having dedicated apis are different levels of caring about the wrapper and i'm feeling more on the former [13:46:44.0405] I think the current wrapper semantics are fine [13:46:58.0621] I don't like `isRecord` for the wrapper semantics [13:46:59.0898] snek: same [13:47:04.0126] otherwise I'm fine with it [13:47:31.0313] well, the wrapper semantics are the entire point of `isRecord` existing [13:47:37.0030] right [13:47:44.0963] so, don't have that [13:48:00.0485] I'd be OK with omitting this operation; I'd also be OK with adding a weird predicate Record.isRecordWrapper [13:48:14.0821] i'm personally fine with the `is` methods existing under the assumption that i will never see them being used outside of occasionally reading code from jordan's es-whatever packages [13:48:39.0843] yeah, `isRecordWrapper` is certainly a lot more palatable [13:48:44.0701] * i'm personally fine with the `is` methods existing under the assumption that i will never see them being used outside of occasionally reading code from jordan's es-whatever packages [13:49:04.0038] wait yeah try-catch does this already [13:49:05.0748] isRecordObject [13:49:07.0471] try-catch solves this perfectly [13:49:09.0558] we should do that 100% [13:49:13.0443] how? [13:49:36.0700] console.log in node can use native apis from v8 [13:49:40.0234] we don't need Record.isRecord [13:49:45.0013] yes [13:50:04.0712] > <@devsnek:matrix.org> console.log in node can use native apis from v8 It could also just print record wrappers as normal objects [13:50:06.0772] and it already does for things like the isProxy detection code [13:50:19.0520] `isRecord(x)` is exactly `typeof x === 'record' || try { Record.omit.call(x, 'a'); return true; } catch { return false }` [13:50:32.0949] if I understand correctly [13:50:33.0851] yeah we like, reach into weakmaps and stuff to print out their values, we are very far from needing stdlib support for stuff :P [13:50:37.0196] bakkot: The proposal doesn't currently include `.omit` [13:50:48.0193] true [13:50:51.0936] but if it did that would work [13:50:54.0342] Is there a mechanism to unwrap a Record wrapper if there's no `.valueOf`? [13:51:02.0858] > <@bakkot:matrix.org> to be clear, these exotic wrappers only come up when you invoke a method (presumably with `.call`) in sloppy code with the record or tuple as its `this` also an explicit `Object()` call [13:51:08.0063] > <@rbuckton:matrix.org> Is there a mechanism to unwrap a Record wrapper if there's no `.valueOf`? If wrappers are immutable, `Record(wrapper)` [13:51:28.0624] Ah, thanks. [13:51:36.0490] > <@bakkot:matrix.org> but if it did that would work True (and maybe it would be nicer than `.isRecordWrapper`) [13:51:43.0660] rkirsling: did you volunteer to review? [13:51:51.0273] trying to capture reviewers in the notes [13:52:05.0334] > <@littledan:matrix.org> more like "true statement" > a statement or proposition which is regarded as being established, accepted, or self-evidently true. yes, that's what axiom means [13:52:25.0255] no, "happens to be true" is very different from "is an axiom" [13:52:32.0589] yes [13:52:36.0855] > <@nicolo-ribaudo:matrix.org> If wrappers are immutable, `Record(wrapper)` Not 100% sure why that is a requirement: ```js var obj = Object(1); obj.x = 2; obj.x; // 2 var i = Number(obj); i; // 1 i.x; // undefined ``` [13:52:39.0366] > <@nicolo-ribaudo:matrix.org> If wrappers are immutable, `Record(wrapper)` that would work whether they're mutable or immutable. [13:52:51.0443] Because `Record(...)` just copies the enumerable keys from the argument [13:53:02.0511] * Because `Record(...)` just copies the enumerable keys from the argument [13:53:13.0387] it shouldn't, if it's passed a wrapper [13:53:14.0695] Then it's not "unwrapping" the wrapper, its constructing a new record, which is not the same. [13:53:20.0780] it should just extract the slot and return it. if not, that's a bug [13:53:32.0264] > <@rbuckton:matrix.org> Then it's not "unwrapping" the wrapper, its constructing a new record, which is not the same. How is that different since two records with the same contents are the same record? [13:53:38.0890] the slide should say `mod instanceof WebAssembly.Module` i believe [13:53:45.0599] * the slide should say `import module foo from "./bar.wasm"` i believe [13:54:10.0984] Its different for the exact reason mentioned above. if it copies enumerable keys then it might construct a *new* record if its mutable, so its not unwrapping in that case. [13:54:12.0405] * the slide should say `mod instanceof WebAssembly.Module` i believe [13:54:35.0607] > <@ljharb:matrix.org> it should just extract the slot and return it. if not, that's a bug ```js let myStr = new String("abc") myStr.toString = () => "def"; String(myStr) // "def" ``` ```js Boolean(Object(false)) // true ``` [13:54:42.0369] there is no difference between a "new record" with the same values, and the old record [13:54:45.0798] they are the same value [13:54:53.0996] > <@rbuckton:matrix.org> Its different for the exact reason mentioned above. if it copies enumerable keys then it might construct a *new* record if its mutable, so its not unwrapping in that case. So it only matters if they are mutable [13:55:01.0371] filed https://github.com/tc39/proposal-record-tuple/issues/329 [13:55:14.0807] > <@rbuckton:matrix.org> Its different for the exact reason mentioned above. if it copies enumerable keys then it might construct a *new* record if its mutable, so its not unwrapping in that case. * So it only matters if they are mutable: if they are immutable, that's unwrapping [13:55:16.0517] > <@bakkot:matrix.org> rkirsling: did you volunteer to review? yup! [13:55:37.0499] oh i see, yeah if its enumerating and non-mutable it would pick up extended properties on the wrapper [13:55:38.0628] thank [13:55:56.0327] > <@nicolo-ribaudo:matrix.org> So it only matters if they are mutable: if they are immutable, that's unwrapping If record wrappers are mutable, then I'd want *some* mechanism to unwrap like valueOf [13:56:13.0160] > <@rbuckton:matrix.org> If record wrappers are mutable, then I'd want *some* mechanism to unwrap like valueOf Yes, I agree [13:56:36.0241] The current proposal is that record wrappers are immutable. We're still waiting on a concrete scenario presented which justifies otherwise. [13:57:06.0133] honestly I kind of like just not having wrappers [13:57:13.0402] make it so `Object(record)` makes a copy [13:57:15.0162] wrappers are evil [13:57:18.0501] * wrappers are evil [13:57:33.0330] We did some extensive work into analyzing a no-wrappers version. After a lot of discussion, it wasn't adopted [13:57:48.0902] but actually I think in that version Object(record) just returned record [13:58:00.0648] bakkot: I'd rather not have records be special in this way [13:58:05.0393] `Object(x)` returning a primitive would be quite bad [13:58:13.0395] well, in this case, it'd be an object [13:58:33.0776] > <@michaelficarra:matrix.org> `__proto__` not being allowed is unfortunate but understandable to be clear, `["__proto__"]` is allowed as a way to add that as a string prop. It's only the bare syntax which is dissallowed [13:58:59.0807] to match the object literal semantics for when it's setting the proto or not [13:59:04.0243] * to match the object literal semantics for when its setting the proto or not [13:59:08.0313] * to match the object literal semantics for when it's setting the proto or not [13:59:29.0976] > <@ljharb:matrix.org> `Object(x)` returning a primitive would be quite bad tbc the proposal was to make a new object with the same keys/values as the record [13:59:50.0618] right I'm just referring to the version that we spelled out in a bunch of detail [13:59:56.0075] (you can't "make a copy" of a record) [14:00:12.0998] isn't this what we have the difference between `Object()` and `new Object()` for [14:00:46.0519] or like, not *why*, but we happen to have this annoying difference [14:01:16.0218] oh god, don't ever put `new` in front of one of those constructors [14:01:48.0573] you don't do new Number() to be OO in your math? [14:03:19.0902] > <@littledan:matrix.org> The current proposal is that record wrappers are immutable. We're still waiting on a concrete scenario presented which justifies otherwise. One possible usage of mutable is: `let x = #{foo:1}; x = alter(x, x=>x.foo++); assert.equal(x, #{foo:2}); function alter(r, f) { let o = Object(r); f(o); return Record(o) }` [14:04:09.0716] A use case wouldn't just be code but also an explanation of why we want to do this [14:04:56.0765] HE Shi-Jun: You could just use `{ ...r }` instead of `Object(r)` [14:09:09.0184] > <@nicolo-ribaudo:matrix.org> HE Shi-Jun: You could just use `{ ...r }` instead of `Object(r)` yeah, u could. I just feel current `Object(primitive)` always give a mutable objects. [14:11:20.0878] > <@littledan:matrix.org> A use case wouldn't just be code but also an explanation of why we want to do this I'm ok with `Object(record)` returns an immutable object, I just wrote an example which might use mutable version. [14:11:33.0223] Btw, `alter("abc", s => s[1] = "d"); function alter(r, f) { let o = Object(r); f(o); return String(o) }` doesn't currently return `"adc"` [14:19:16.0275] nicolo-ribaudo: `alter` is just a mimic of current userland immutable library (see https://leontrolski.github.io/alter.html ), so I don't expect people would use that to alter strings... 😅 [14:26:22.0149] "can this be imported" seems like major semantics but I guess I am ok deciding that at stage 2 instead of before [14:29:15.0799] the import keyword is important to make things syntactically unambiguous [14:29:54.0616] eh, it seems fundamental to me that if we're reflecting stages of the module pipeline, the verb `import` necessarily becomes overloaded [14:30:09.0020] but that seems fine to me from a readability perspective [14:30:27.0589] like, it seems worse if, for the sake of the english word being unambiguous, we had a form like `import.instantiate(x)` [14:31:23.0403] we shouldn't place much if any weight on the actual english definition of import as it relates to its place in the module pipeline. import is already super ambiguous in english anyway [14:31:35.0638] so i guess +1 [14:33:41.0832] syntax budget definition is up for someone to review: https://github.com/tc39/how-we-work/pull/116 [14:44:53.0387] > <@rkirsling:matrix.org> syntax budget definition is up for someone to review: https://github.com/tc39/how-we-work/pull/116 looks good but can we somehow work a jab at perl into this definition [14:45:54.0965] ``` ### Counterexamples Perl ``` [14:46:23.0736] there's also https://www.stroustrup.com/P0977-remember-the-vasa.pdf [14:46:37.0748] yeah I thought about linking that [14:46:38.0255] though I guess that's not just syntax [14:46:55.0026] but it's ever so slightly different [14:47:01.0906] https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 is possibly a better link [14:47:08.0640] was it dan who gave the presentation at like, 2019 microsoft maybe, showing all our syntax combined [14:47:15.0091] oh yeah, that's the one I forgot about [14:47:18.0087] * was it dan who gave the presentation at like, 2019 microsoft maybe, showing all our syntax combined [14:47:18.0197] leo, maybe? [14:47:24.0471] i remember that presentation it was fun [14:47:29.0739] i remember everyone laughing [14:47:48.0856] yeah that was Leo; I found that sample a little unfair [14:47:57.0416] I mean, you can write messy stuff in ES3 [14:48:09.0373] well the examples were unrealistic [14:48:12.0406] to some degree [14:48:24.0138] can confirm, own an es5 environment, you dont need new syntax to do bad things. I've seen things. [14:48:52.0947] `new Array(n)` is worse than hitting the syntax budget don't @ me [14:49:05.0337] Leo had a bunch of good ideas in that presentation, but I don't find the "we're about to fall off the complexity cliff!" frame that others have used very revealing [14:49:18.0991] syntax budget only applies to things actually written [14:49:27.0931] > <@devsnek:matrix.org> `new Array(n)` is worse than hitting the syntax budget don't @ me Be grateful that `new Array` does not return an "array wrapper" [14:49:28.0476] like `with` doesn't really count, because, like, you don't have to know about it [14:49:55.0996] * Leo had a bunch of good ideas in that presentation, but I don't find the "we're about to fall off the complexity cliff!" frame that others have used very revealing [14:49:59.0938] a few of the proposals were simplified though [14:50:24.0317] on the other hand `match` has like 4x as much syntax now [14:50:47.0294] yulia's document she posted yesterday was so well done [14:50:54.0981] link? [14:51:07.0336] or dm me if it's not public I guess [14:51:15.0166] https://github.com/tc39/proposal-pattern-matching/issues/281 in the OP [14:51:17.0545] * https://github.com/tc39/proposal-pattern-matching/issues/281 in the OP [14:57:41.0888] not sure how I feel about adding a new `eval` [14:57:53.0166] even one where the code being eval'd must be granted permissions explicitly [14:59:05.0016] Where is the new eval? [14:59:45.0472] In the "Evaluators" part [14:59:53.0928] Ah! [14:59:58.0188] `ModuleSource` as being proposed on a previous slide took a string and produced a module object which could be evaluated [15:00:12.0540] * `Module` as being proposed on a previous slide took a string and produced a module object which could be evaluated [15:00:14.0769] * In the "Evaluators" part [15:00:56.0073] Need "need notetakers" on that bingo card [15:01:20.0363] wait, we don't? [15:01:28.0396] oops, also #temporaldeadzone:matrix.org [15:01:39.0189] http://j.mp/tc39bingo could be customized :-p [15:03:38.0373] What does "&c" mean? [15:03:50.0179] I assume "and company" [15:03:50.0521] "etc" [15:03:56.0673] ^ [15:04:02.0234] * "etc" [15:04:23.0732] andcetera [15:04:35.0236] * andcetera [15:04:35.0633] it's where "et cetera" came from, i believe [15:04:41.0502] fair [15:05:14.0520] It's important to understand IMO that these layers are not necessarily "this proposal comes before that one" or "they all eventually happen" but just a way to understand the whole conceptual space that we're working within, in modules [15:05:19.0877] It's a great way to understand it IMO [15:05:24.0224] * it's where "et cetera" came from, i believe (actually, googling suggests that it's just a historical abbreviation of the full etc) [15:07:03.0938] We need consensus to customize? :D [15:12:46.0535] > <@bakkot:matrix.org> like `with` doesn't really count, because, like, you don't have to know about it I use it everyday, in our production code! [15:13:20.0033] > <@jackworks:matrix.org> I use it everyday, in our production code! Is `new Evaluators` the `with`-killer we need? [15:13:43.0508] well now that you've said this you can't unsay it :) [15:14:13.0834] that was a "you" meaning, like, normal people, not the people in this room. I also have to know about B.3.3 but no one else should [15:14:30.0877] > <@nicolo-ribaudo:matrix.org> Is `new Evaluators` the `with`-killer we need? I'm gradually switching (but not done) to Ahead-of-time compiling to Virtual Modules based on today's presentation of Compartments. [15:15:41.0662] > <@bakkot:matrix.org> that was a "you" meaning, like, normal people, not the people in this room. I also have to know about B.3.3 but no one else should high bus factor on B.3.3, do you have an apprentice? [15:16:22.0040] > <@hemanth.hm:matrix.org> We need consensus to customize? :D Hemanth H.M: are you fundamentally advocating that we relitigate the bingo card? we should defer the bikeshed of this meta-argument to userland until we can reach consensus on this scenario. let me finish. [15:16:29.0898] Maybe a bus factor of 1 is exactly what B.3.3 needs [15:16:34.0772] snek: my plan is to die and for it to become lost knowledge [15:16:54.0471] lol [15:16:55.0326] nicolo and bakkot in solemn agreement [15:17:01.0404] * nicolo and bakkot in solemn agreement [15:17:54.0608] nicolo-ribaudo: we're not letting you drive a bus anymore [15:17:59.0101] (to be clear in actual fact a few other delegates have at least as much knowledge here as I do, though most of us do try to keep it paged out as much as possible) [15:19:26.0543] > <@usharma:igalia.com> nicolo-ribaudo: we're not letting you drive a bus anymore Driving bus is not in my daily acitvities list [15:19:56.0207] everybody likes to complain about B.3.3, but the rest of B.3 is just as worthy of your derision [15:20:35.0838] We get bug reports in Babel for not properly supporting B.3 [15:21:12.0555] from a set of how many people tho [15:21:19.0245] labeled function declarations are merely useless, not horrifying [15:21:27.0293] * from a set of how many people tho [15:21:55.0435] > <@ljharb:matrix.org> from a set of how many people tho At most 3 [15:21:59.0819] also I guess it's actually B.3.2 now? which thing did we remove... [15:22:17.0586] add em to the bus list [15:22:18.0806] :) [15:22:19.0368] B.3.4 and B.3.5 are pretty bad [15:22:38.0849] oh, `__proto__` in object literals, of course [15:22:40.0541] yeah B.3.3 isn't so bad by comparison [15:23:25.0574] > <@littledan:matrix.org> yeah B.3.3 isn't so bad by comparison Well, B.3.3 (functions in if) is just "in this case, do what B.3.2 says" (functions in bloks) [15:23:42.0651] > <@bakkot:matrix.org> also I guess it's actually B.3.2 now? which thing did we remove... wait what [15:23:48.0064] do I need to update the article [15:23:49.0428] * do I need to update the article [15:23:59.0124] I will always think of it as B.3.3 [15:24:06.0491] but yes we removed `__proto__` and things got moved around [15:24:07.0011] ring the bell, Annex B has changed [15:24:21.0117] Editors, can we add an empty B.3.2 section and restore the correct numbers? [15:24:28.0811] ... tempting [15:24:38.0718] (B.3.1 technically) [15:25:11.0025] (jokes aside, being able to skip clause numbers in ecmarkup is something both ljharb and me would like) [15:25:21.0073] > <@nicolo-ribaudo:matrix.org> Editors, can we add an empty B.3.2 section and restore the correct numbers? * (jokes aside, being able to skip clause numbers in ecmarkup is something both ljharb and me would like) [15:25:31.0821] PRs welcome [15:25:43.0322] PR will come [15:26:22.0018] put a `clause-number` attribute on emu-clause or something [15:26:45.0881] that would be so amazing. especially if it auto-numbered from that point [15:26:54.0594] ofc [15:27:41.0239] p0 is dark theme [15:27:59.0360] dark reader extension works ok [15:28:12.0920] you're supposed to be temporarily blinded whenever you read the spec, it's intentional [15:28:21.0360] if you want to find someone who can actually do design to make us a dark theme, including the variable highlight stuff, go for it [15:28:24.0628] I am... not a designer [15:28:51.0647] we just need colors, right? [15:28:53.0346] nothing else [15:29:17.0759] with the dark reader extension ^ [15:29:29.0786] what does it look like when you click a variable? [15:29:33.0515] or a couple varaibles [15:29:41.0239] yeah, what if we just used the inverted version of every single existing color? [15:29:50.0139] dark reader doesn't just invert [15:30:05.0306] gross [15:30:10.0941] yeah, but if we did that as a dark mode MVP, would it be decent? [15:30:14.0222] idk seems fine [15:30:19.0084] i can play with this [15:30:19.0810] gotta get better colors for the highlights [15:30:20.0552] > <@usharma:igalia.com> yeah, what if we just used the inverted version of every single existing color? er well notes should remain green, say [15:30:22.0259] at some point [15:30:25.0087] like just to pull the color codes from [15:30:28.0982] i am technically a frontend developer [15:30:49.0804] discord does a very good job of dark mode [15:30:58.0608] unlike GH's sorry first attempt [15:31:08.0769] i've never understood the appeal of dark mode personally [15:31:09.0953] yeah i'll just copy discord's colors /s [15:31:16.0581] you have magic eye jordan [15:31:27.0954] my optometrist would disagree [15:31:31.0929] > <@devsnek:matrix.org> yeah i'll just copy discord's colors /s purple spec when [15:31:37.0860] blurple* [15:32:02.0122] Can we load vscode themes? [15:32:03.0449] i also do not use dark mode [15:32:18.0640] sublime text 2 themes [15:32:48.0715] dark mode comes from late night lights off pc usage and not wanting to flashbang your eyeballs [15:32:48.0850] possibly we should take this to tdz [16:00:08.0872] "I hate that Kris started counting from 0" ~ me one hour before the meeting [16:04:06.0656] For the earlier discussion about wrapper-less Records and Tuples, see https://github.com/tc39/proposal-record-tuple/issues/201 [16:38:35.0071] I'm wondering if we can add { a as b } as the replacement of { a: b } which is unreadable 2022-07-20 [21:51:57.0446] Jack Works: Type annotation proposal also include `as` 😉 [07:52:58.0629] Userland as would be possible with rbuckton ‘s Extractors 😃 let As = {[Symbol.extractor]: x => x}; let { a: As(b) } = … [07:54:40.0369] > <@jackworks:matrix.org> I'm wondering if we can add { a as b } as the replacement of { a: b } which is unreadable * Userland as would be possible with rbuckton ‘s Extractors 😃 let As = {[Symbol.extractor]: x => x}; let { a: As(b) } = … [07:58:27.0662] * Userland as would be possible with rbuckton ‘s Extractors 😃 ``` let As = {[Symbol.unapply]: x => x}; let { a: As(b) } = … ``` [07:58:38.0270] * Userland `as` would be possible with rbuckton ‘s Extractors 😃 ``` let As = {[Symbol.unapply]: x => x}; let { a: As(b) } = … ``` [08:00:55.0437] > <@waldemarh:matrix.org> What does "&c" mean? Sorry, this is a typography nerd-snipe I use habitually. As others inferred, it's even shorter than "etc", "et cetera", "and so on", taking advantage of & historically coming from a ligature of et, meaning "and" in Latin. There’s precedent but hasn’t been common for a couple hundred years. [08:10:24.0298] (I use &c. in my patient notes all the time. 🥲) [08:16:55.0855] a question from the discourse: should `/^a[^a]$/u.test('a\u{1f310}')` be `true` or `false`? [08:20:42.0884] at first glance it seems like it should be false, assuming there’s only two code points in the string, one of which is a? [08:27:49.0740] note that this is a u-mode regexp, which matches by code points [09:02:09.0992] `true`? Are char classes only speced to operate on u16 chars? [09:06:31.0217] y'all are very bold for trying to decode what a regex should do with the annex b situation [09:08:01.0015] engine262 says true [09:13:07.0565] Do we want the notes to say (“Ecma262” or “ECMA-262”) and (“Ecma402” or “ECMA-402”)? [09:13:16.0289] * Do we want the notes to say “Ecma262” or “ECMA-262” and “Ecma402” or “ECMA-402”? [09:13:27.0912] i would imagine the latter? [09:14:15.0359] * Do we want the notes to say (“Ecma262” or “ECMA-262”) and (“Ecma402” or “ECMA-402”)? [09:17:45.0089] `/^a[^]$/u.test('a\u{1f310}') === true`... [09:26:43.0368] Breakfast is served [09:26:52.0483] (more than yesterday) [09:28:11.0182] looks delicious [09:29:17.0604] I hope one day I can come to the in person meeting 👀 [09:31:23.0937] Shu and Shane have not yet arrived yet. Please shout here if you are in the visitor entrance and need a Googler to let you through. [09:34:55.0613] Marks let us in but has the dilemma of not being allowed to leave me and Ross unattended. [09:35:23.0080] * Markus let us in but has the dilemma of not being allowed to leave me and Ross unattended. [09:38:33.0964] Bradford has arrived. Meaning we now have two Googlers and can begin the accompanied shuttle service of getting folk through security. Bradford is on his way down now. [09:39:09.0418] * Bradford has arrived. Meaning we now have two Googlers and can begin the accompanied shuttle service of getting folk through security. Bradford is on his way down now. [09:43:13.0532] https://puzzlefry.com/puzzles/fox-chicken-and-corn-river-crossing-popular-puzzle/ [09:54:23.0089] should we say our name before we make a comment? [10:05:08.0957] TLA [10:05:35.0643] note that some people have two-letter acronyms (TLAs) [10:06:00.0595] At least for remote people, can we ask to put acronyms in the google meet name? [10:06:29.0991] If that's helpful [10:07:05.0666] Google Meet doesn’t make it easy to change your display name; it looks like you have to change your Google account personal name… [10:07:50.0194] you can (and should) join in private browsing mode to set a name, which should include your company name [10:08:37.0962] Ah, so I should join without a Google Account. [10:08:58.0750] for feedback, can we just use a Reflector thread instead of having a session in plenary? [10:11:20.0338] The quality of the notes is really excellent [10:11:24.0449] totally agree that some of the ancient notes from like ARV's time miss a ton of nuance [10:11:37.0160] I am watching them and it is impressive [10:12:02.0650] yeah its kinda nuts [10:12:06.0815] these notes are excellent [10:13:00.0549] sorry for not mentioning my TLA 😭 [10:13:11.0476] we got you ryzokuken [10:13:28.0734] thanks 🙏 was going to the notes to help [10:14:39.0715] yeah, this is _way_ better than the bot [10:16:09.0940] also, the bot was _also_ not capturing summaries or anything; I think the relevant question is "is stenography a strict improvement over me running the bot" and I am pretty sure the answer is a resounding yes [10:16:29.0341] (except that we do need to make a point of capturing conclusions still) [10:17:24.0940] there are other ways that notes could be improved probably, but I think those questions need not be addressed right now [10:17:33.0479] to be fair to critics, I think we have *way* more eyes on the notes at the moment than we ever had with the bot [10:18:03.0463] re: speakers identifying the points they want recorded in the notes this is an undue burden on speakers, and in practice would rarely be emphasized [10:18:32.0261] to be fair to the stenographers, they're thrown right into the TC39 frying pan. [10:19:09.0013] i don't see how more notes would ever be bad [10:19:31.0583] as long as they are accurate ideally we write down every word [10:19:39.0220] > <@softwarechris:matrix.org> re: speakers identifying the points they want recorded in the notes > > this is an undue burden on speakers, and in practice would rarely be emphasized importantly, this would be more relevant for verbose, quick back and forths than a long presentation or something, which is where we usually miss details [10:19:40.0100] i cant imagine why we wouldnt if we can [10:19:50.0271] can confirm, I have tried to figure out why historical decisions were made from the notes which predate me and they are often totally unhelpful [10:20:22.0489] so we'll be asking people to pause in the middle of these discussions and specify what they'd like to be transcribed essentially [10:21:12.0502] caridy: btw, the rational project interlinks proposals to their discussions and decisions [10:21:30.0658] it also finds similar discussions -- so you can find similar trees that might impact your proposal [10:21:56.0198] > <@rick.button:matrix.org> i don't see how more notes would ever be bad well, I suppose there's some benefit in reading summaries [10:22:07.0549] but as we talked about, summarizing things well is _very_ hard [10:22:16.0287] we used to have someone summarizing -- it is hard [10:22:23.0830] but i was doing it as well, i need to catch up on recent ones [10:22:28.0579] summarizing things well during a verbose, quick discussion is nearly impossible [10:23:01.0334] so I agree that it's more practical for us to register every word [10:23:11.0481] I would not trust a summary without the source material. and also, many times the summary is not what I am after, but looking for in the moment sentiment from members that aren't part of the champion group i.e. who selects the summary [10:23:59.0626] littledan: FWIW, if we have a professional stenographer service, I'd love for TC39 to have a transcription and a (very) reduced/concise notes from the meeting capturing only major highlights and resolutions from each topic. Knowing we may have a full transcription, notes can be really small, and rich of actionable items looking ahead the meeting. [10:25:03.0826] well, yes, summaries were already good and you, personally, did a lot of good work towards them [10:25:07.0996] I think this is pretty orthogonal? [10:25:26.0822] I don't think a transcriptionist changes the priority of summaries [10:25:41.0069] agree [10:25:47.0244] bottom line is that pro steno is a big improvement over the status quo, and we have yet to hear about any better concrete solutions [10:26:04.0521] littledan: I don't think it's orthogonal. The concise notes I'd love to have are only possible if we have a source of truth for verification (transpilation). Similar to the concern @rickbutton raised. [10:26:21.0509] leobalter: We already try to take a source of truth. A summary is good in any case. [10:26:42.0467] The current source of truth demands a lot of work, as reported, right? [10:26:54.0463] isn't that what is being solved right now? [10:27:04.0704] > <@softwarechris:matrix.org> bottom line is that pro steno is a big improvement over the status quo, and we have yet to hear about any better concrete solutions how about this: we tell the note-takers to do a better job, in a way that they say they can't? (sarcastic) [10:27:23.0755] yeah I have a lot of trouble understanding what caridy and leobalter have been arguing [10:27:49.0033] To msaboff 's point, to take summaries on-line I think we'd need volunteers to implement it. The current people putting in the work to take notes have said it is infeasible for them. [10:27:49.0762] I'm supportive of the stenography but I'm confused by irony in the chat. [10:28:01.0213] level up [10:28:07.0820] that is very ominous [10:28:15.0588] git gud [10:28:39.0944] Kevin is definitely giving the stenographer a hard time with this speed [10:28:43.0026] I mean, during the discussion some people made demands of note-takers, saying that this would make a stenographer unnecessary [10:29:08.0215] and this is something that the note takers responded was inviable for them [10:29:15.0978] so, I don't see that as a proposed solution [10:29:16.0747] silly question -- has anyone considered inline // comments in the actual spec explaining decisions, possibly stable-linked back to the notes document where the discussion occurred? [10:29:38.0831] what I'm saying is: stenography might solve one problem. What I want is not resolved by it alone. I still want concise notes I can quickly browse. I want it to be a bit more than a summary like what we did in the past. I want it to be less verbal than notes were before (when Rick Waldron used to take them). I want the transcription so I can consult and clarify anything if necessary. [10:29:42.0813] inline comments would get dropped when "rendering" the spec [10:30:06.0519] apaprocki: Yes, this is what notes are for. Historically many people were against too many notes, now people are more in favor of more notes, and also we have "editor's notes" which can be removed/maybe collapsed. At this point it'd just be a lot of work to write the notes [10:30:22.0032] I think a lot of people share in those wants -- question is what are the means to those ends? [10:30:34.0626] I think we need transcription for the base material, and then we can do these additional projects of a summary or more notes on top of that [10:30:43.0682] I'm really confused by people positioning one thing against another [10:30:53.0929] > <@littledan:matrix.org> apaprocki: Yes, this is what notes are for. Historically many people were against too many notes, now people are more in favor of more notes, and also we have "editor's notes" which can be removed/maybe collapsed. At this point it'd just be a lot of work to write the notes but the point would be more like C++ comments -- things explicitly not seen when viewing the spec outside of your editor when modifying it [10:31:11.0657] Yeah, that could be done. It would be easy to add collapsable notes. the hard part is to write all of them [10:31:19.0541] I think we should add such notes [10:31:24.0488] I am also not signing up to do it [10:31:28.0359] @littledan I never said I'm against other positions. I'm supportive of progress for stenography, and shared my vision going further. [10:32:20.0291] I agree with this supportive vision; I was just overreacting above due to the unexpected negativity [10:32:24.0503] maybe fix it going forward? -- if decisions were made, why not make it part of the spec text and it's the champions' responsibility to record those notes/comments explaining the decision at spec text review time [10:32:41.0501] apaprocki: Yes, I agree we should add more notes [10:32:51.0875] there's another thing where sometimes we just disagree internally about the rationale for something [10:33:10.0554] that's fine, both viewpoints could be recorded and noted [10:33:16.0278] so, notes saying who said what is a sort of more neutral document, even if it's harder to scan [10:33:36.0348] > <@apaprocki:matrix.org> that's fine, both viewpoints could be recorded and noted I think this would be a bit much to have in the main spec, but maybe would be good in some notes summary doc. It gets a little talmudic... [10:33:46.0818] ``` async function* outer() { yield Promise.resolve(1); try { Promise.reject(1) } catch {throw new Error("err")}} ``` ``` (await outer()).next(); // this doesn't throw const x = (await outer())) await x.next(); await x.next(); // throws ``` trying to understand that behavior. [10:33:52.0652] we should let the stenographers know they don't need to record the like "can you hear me?" and other chair-related meta-content [10:34:02.0903] my main pain point in the past was that there was no link between recorded spec text and the notes documents/meetings where they were discussed [10:34:11.0493] you had to waste time going around fishing for what meetings were involved [10:34:19.0694] hope your grep would find it [10:34:37.0780] littledan: FWIW, I can't ask anyone to capture highlights and resolutions in the meeting in a separate document if people are already overwhelmed doing transcription or reviewing the bot transcription. [10:35:20.0342] leobalter: but isn't the proposal to hire people to do the transcription? so that we are no longer doing that? That would mean people are no longer overwhelmed [10:35:29.0011] > <@apaprocki:matrix.org> my main pain point in the past was that there was no link between recorded spec text and the notes documents/meetings where they were discussed I think we still never link from the spec to the notes, we just include some notes in the spec [10:35:34.0784] Michael Ficarra: we should not worry about it (if they do it or not) for the sake of clear transcriptions. [10:36:01.0875] leobalter: it might help them catch up, we are going a little fast for them it seems [10:36:05.0198] > <@usharma:igalia.com> I think we still never link from the spec to the notes, we just include some notes in the spec yeah.. curious if there's an active reason why that isn't done or if we just haven't discussed it [10:36:29.0193] I've always thought the pass-through of `value` in `for-await` was a mistake [10:37:16.0928] yulia: I'm supportive to this, what I want is a really small doc, done in parallel with said transcription, with only highlights. By highlights I mean 3 bullet points + and other bullet points with resolution. [10:37:25.0103] On my way. [10:37:38.0372] > <@leobalter:matrix.org> yulia: I'm supportive to this, what I want is a really small doc, done in parallel with said transcription, with only highlights. By highlights I mean 3 bullet points + and other bullet points with resolution. I see, great -- Sorry my attention is split [10:37:59.0984] So, to tie this together, it'd be great to get professional support for transcriptioning so that we can put the notes effort into this higher level work of creating summaries of rationales and linking them to the spec. [10:38:28.0190] I would expect "delivering a promise" here to require wrapping it. [10:39:25.0082] yulia: and to repeat myself: I don't think it's fair to ask anyone to capture those highlights if we are already doing a lot with the current notes we have today. The stenographer transcription would work great supporting this highlight document and any other summary people would eventually write. [10:39:31.0276] Would we expect `Array.fromAsync` to also pass through a Promise in `value`? [10:39:54.0322] > <@rbuckton:matrix.org> I would expect "delivering a promise" here to require wrapping it. That’s odd because async iterators transport T, not Promise. The promise is Promise> not Promise>> [10:40:06.0849] > <@leobalter:matrix.org> yulia: and to repeat myself: I don't think it's fair to ask anyone to capture those highlights if we are already doing a lot with the current notes we have today. The stenographer transcription would work great supporting this highlight document and any other summary people would eventually write. great, thanks for clarifying -- it wasn't clear from what i managed to glean glancing back and forth [10:40:17.0550] My plan is to match `for await`, whatever happens. (Note that if a mapping function is provided, it is considered an async function and its results are always awaited.) See also https://github.com/tc39/proposal-array-from-async/issues/19#issuecomment-1179810964. [10:40:21.0093] > <@littledan:matrix.org> So, to tie this together, it'd be great to get professional support for transcriptioning so that we can put the notes effort into this higher level work of creating summaries of rationales and linking them to the spec. leobalter: OK, does this comment summarize your thoughts then? [10:40:37.0108] > <@rbuckton:matrix.org> Would we expect `Array.fromAsync` to also pass through a Promise in `value`? * My plan is to match `for await`, whatever happens. (Note that if a mapping function is provided, it is considered an async function and its result is always awaited.) [10:40:40.0861] * My plan is to match `for await`, whatever happens. (Note that if a mapping function is provided, it is considered an async function and its results are always awaited.) [10:40:53.0986] The fact that a manually crafted *sync* iterator's `value` is awaited but a manually crafted *async* iterators is not is inconsistent [10:41:26.0332] * My plan is to match `for await`, whatever happens. (Note that if a mapping function is provided, it is considered an async function and its results are always awaited.) See also https://github.com/tc39/proposal-array-from-async/issues/19#issuecomment-1179810964. [10:41:33.0592] > <@littledan:matrix.org> So, to tie this together, it'd be great to get professional support for transcriptioning so that we can put the notes effort into this higher level work of creating summaries of rationales and linking them to the spec. Re: stenography - as note takers we are able to add more value to the notes that way: for instance we can also describe what the speaker is currently showing, adding more context: for instance KG is showing that issue, we could add it to the notes instead of playing catch up with the bot [10:41:52.0618] littledan: not only the given effort but having the transcriptions functioning as the source of truth for said summaries. This is important if anyone wants to verify info. [10:42:12.0078] (so is that a yes?) [10:42:17.0275] I think we're in violent agreement [10:42:23.0836] great [10:42:37.0262] the best kind of agreement [10:43:33.0314] let's agree to agree [10:43:37.0088] * ``` async function* outer() { yield Promise.resolve(1); try { Promise.reject(1) } catch {throw new Error("err")}} ``` ``` (await outer()).next(); // this doesn't throw on multiple calls const x = (await outer())) await x.next(); await x.next(); // throws ``` trying to understand that behavior. [10:43:43.0518] * ``` async function* outer() { yield Promise.resolve(1); try { Promise.reject(1) } catch {throw new Error("err")}} ``` ``` (await outer()).next(); // this doesn't throw on multiple calls const x = (await outer())) await x.next(); await x.next(); // throws ``` trying to understand that behavior. [10:44:53.0354] /cc snek [10:45:47.0214] you mean cc bakkot? [10:46:00.0065] * you mean cc bakkot? [10:46:21.0064] you didn't yield the Promise.reject though [10:46:28.0866] * /cc bakkot [10:46:56.0333] ha, yes. [10:47:00.0578] Not entirely thrilled with the direction (removing an implicit await in `yield*`), but won't block. I'll have to test this change in my own projects, as I *may* have code that could break with this change given assumptions about `yield*` today [10:49:15.0424] rbuckton: It'd be great to hear about the results of that [10:51:41.0093] RegExp subclassing was a horrible mistake and the committee should've accepted my proposal to remove it [10:52:55.0417] can't we still? [10:54:11.0754] It'd take some investigation into how frequently the full case comes up, to understand whether it's web-compatible [10:54:20.0403] i mean, our implementation uses v8's implementation so... really they should chime in ;) [10:54:44.0090] well isn't this change at a higher layer to the part where you hook into V8's implementation? [10:54:48.0139] is that irregexp [10:54:55.0331] also all the current ways we determine web compatibility would need to be able to separate out "core-js" and "everything else", since core-js has a ton of regexp feature tests that serve as false positives. [10:55:08.0198] > <@devsnek:matrix.org> is that irregexp yup [10:55:36.0987] XRegExp also presented some issues with web compatibility of shipping RegExp subclassing; IIRC we made some tweaks due to that [10:55:37.0513] * also all the current metrics-gathering approaches browsers use to determine web compatibility would need to be able to separate out "core-js" and "everything else", since core-js has a ton of regexp feature tests that serve as false positives. [10:55:47.0949] in retrospect we should've just pushed back harder [10:56:03.0135] i'm sad that v8's experimental regex interpreter didn't pan out more [10:57:47.0516] wait, so is safari's output for `String.prototype[Symbol.iterator].toString()` compliant? (starts with `function [Symbol.iterator]() {`) [10:58:47.0745] ryzokuken: bterlson Rob Palmer Could we add a 10-minute agenda item tomorrow to draw a conclusion on the stenography question? [10:59:17.0662] > <@littledan:matrix.org> Yeah, that could be done. It would be easy to add collapsable notes. the hard part is to write all of them fwiw I think the git log is good enough for this already that the additional work is not worth it [10:59:28.0270] git blame + useful PR messages goes a long way [10:59:41.0178] If i were to restate the change here -- are we making the spec more permissive here? [11:00:11.0514] Safari 15.5 returns `"function [Symbol.iterator]() { [native code] }"`. [11:00:17.0794] > <@ljharb:matrix.org> wait, so is safari's output for `String.prototype[Symbol.iterator].toString()` compliant? (starts with `function [Symbol.iterator]() {`) * Safari 15.5 returns `"function [Symbol.iterator]() { [native code] }"`. [11:00:22.0501] right, i'm asking if that's compliant [11:00:30.0655] iain from Mozilla has been working on ICU4X backed I18n aware RegExp particularly to target ECMA-262/ECMA-402 RegExp needs [11:00:50.0134] > <@bakkot:matrix.org> fwiw I think the git log is good enough for this already that the additional work is not worth it Well, so maybe this is just an ecmarkup frontend thing then, to make the blame more accessible in the UI [11:00:54.0870] I'm not sure what the latest status on that is, but dminor or yulia may have the latest ) [11:01:02.0952] > <@ljharb:matrix.org> right, i'm asking if that's compliant https://github.com/tc39/test262/blob/main/harness/nativeFunctionMatcher.js [11:01:08.0877] littledan: searchfox exists and is great [11:01:27.0839] lol this doesn't help me [11:01:30.0141] seems like no? [11:01:34.0574] > If you want to explore how the specification was written, you can also view the source with its history in searchfox [https://searchfox.org/ecma262/source/spec.html]. [11:02:01.0829] I don't think I can possibly do a better job than searchfox [11:02:07.0511] and don't want to duplicate the work [11:02:29.0822] well, a nice-to-have would be to have the blame links integrated with the rendered spec. But I don't want to do this work either. [11:02:31.0759] > <@littledan:matrix.org> well isn't this change at a higher layer to the part where you hook into V8's implementation? Confirmed: all the species stuff happens outside irregexp [11:03:11.0569] > <@bakkot:matrix.org> > If you want to explore how the specification was written, you can also view the source with its history in searchfox [https://searchfox.org/ecma262/source/spec.html]. The searchfox implementation is very good. We might be able to do some additions, but i think pretty much everything you want is there [11:03:27.0379] ljharb: it is valid [11:03:44.0670] i think there was a project that did blame links inline in the spec [11:03:48.0511] i can't remember who did it [11:04:53.0955] aria probably [11:05:14.0586] you know what would be scary. If someone was depending on the toString value as a way to sniff implementations, and making whitespace standard would result in web compat breakage [11:05:23.0378] *cough* [11:05:24.0218] why do i feel like that is eerily likely [11:05:38.0658] https://arai-a.github.io/ecma262-compare/ [11:05:39.0940] there we go [11:05:40.0410] angular 1? [11:05:41.0025] My dream is someday to make a website that does something like this, except it’s for every Unicode character, linking to whatever Unicode L2 proposals involved it. [11:05:51.0874] > <@yulia:mozilla.org> i think there was a project that did blame links inline in the spec * My dream is someday to make a website that does something like this, except it’s for every Unicode character, linking to whatever Unicode L2 proposals involved it. [11:05:54.0180] * angular 1? [11:06:28.0556] > <@bakkot:matrix.org> https://arai-a.github.io/ecma262-compare/ of course it was arai ! [11:06:47.0671] > <@littledan:matrix.org> ryzokuken: bterlson Rob Palmer Could we add a 10-minute agenda item tomorrow to draw a conclusion on the stenography question? we have 50mins free time, so yes, 10 mins has been allocated for stenography continuation [11:07:09.0167] > <@yulia:mozilla.org> of course it was arai ! But does this give you a blame of the spec? [11:07:47.0970] /me idea: like searchfox but for notes [11:07:57.0163] I mean, that would correspond to what apaprocki is requesting [11:08:01.0132] > <@littledan:matrix.org> But does this give you a blame of the spec? Hm, looks like not this project. I distinctly recall that someone did this [11:08:11.0137] One of the issues was it was quite chunky and slow [11:09:09.0739] i would suggest trying out the searchfox version. once you get used to searching through it, it gets really fast and easy to find what you want [11:09:16.0975] and, additionally you can go back in time [11:09:31.0662] if we wanted to do that , we would need to have a render of every change to the spec hosted somewhere [11:09:34.0044] the "going back in time" part is the bit I am most impressed by and most do not want to replicate [11:09:46.0275] > <@yulia:mozilla.org> if we wanted to do that , we would need to have a render of every change to the spec hosted somewhere well, no, ecmarkup is JS and can run client-side [11:10:07.0007] > <@bakkot:matrix.org> well, no, ecmarkup is JS and can run client-side true... but it would be a bit slow [11:10:12.0566] we have everything for search fox already cached [11:10:13.0759] yeah [11:10:16.0219] Yeah, I'm happy to learn about searchfox; I guess the concern was about how to make this all really accessible [11:10:20.0348] that is what makes it so fluid to work with [11:10:27.0522] * Yeah, I'm happy to learn about searchfox; I guess the concern was about how to make this all really accessible [11:10:49.0174] I will make a note to remind people about searchfox in the next editor update [11:11:01.0071] it's linked from the main 262 readme but no one is going to read the readme every day [11:11:04.0589] that would be great -- if there are things we would like to make better about it, let me know [11:11:09.0505] we also cache the html spec and a few others [11:11:17.0988] oh yeah I missed that in the readme [11:11:21.0756] and its actively developed by mozilla [11:11:39.0307] i can't guarantee we would get everything but i can ask [11:12:09.0499] but I imagine this works better for smaller PRs and less well for understanding the motivation of details of larger proposals [11:12:57.0875] yes, thats correct -- we don't track proposal prs [11:13:31.0524] since there is less history in those, im usually able to use git blame for that. But -- we could also host our own instance of searchfox and cache proposals ourselves [11:13:45.0062] i don't think mozilla would be able to do it for all proposals though, so that would be work we would be doing [11:14:06.0048] i _do_ think that due to the much smaller history on most proposals, that this likely won't be worth it [11:14:24.0456] right, I'm not asking you to do it, just trying to say that I doubt searchfox meets apaprocki 's documentation request [11:14:46.0040] ah, got it -- sorry, again flipping back and forth [11:26:59.0725] maybe minority opinion: Ecma should pay for this to be done, just like steno [11:27:18.0691] you misspelled majority /s [11:27:23.0591] * you misspelled majority /s [11:27:57.0030] We actually made a funding request for this already. We agreed on it as a committee, and the editors sent a letter to the secretariat asking for this support. Things kinda got stalled in the phase of selection of a contractor. [11:27:58.0760] apaprocki: I think Ecma *did* pay for this to be done [11:28:26.0184] wait littledan you asked for funding this before asking the rest of the committee!?!?!?!?!?!? 🤯 [11:28:29.0062] Yeah, Allen has been an Ecma contractor before; maybe he was a contractor for this as well (as Ecma VP, I have no transparency into Ecma's contractors) [11:28:43.0623] > <@devsnek:matrix.org> wait littledan you asked for funding this before asking the rest of the committee!?!?!?!?!?!? 🤯 We did discuss this in committee IIRC [11:28:48.0575] they were going to pay PDFReactor [11:29:00.0034] i am happy to put some work into automating this, though I'll need allen's documentation [11:29:04.0087] not sure if they paid Allen to work on this, but I have a feeling that they didn't [11:29:07.0023] I am not willing to spend a week of my life producing a pdf though [11:29:11.0684] * I am not willing to spend a week of my life producing a pdf though [11:29:49.0875] every year* [11:30:26.0656] i'm barely wiling to spend the hour it takes to make it with print-to-pdf plus manual adobe acrobat tweaks [11:31:00.0384] sffc: are there issues with text searching in 2020 or 2021? at some point i switched to Acrobat over Preview so i'd expect that to have been solved [11:33:15.0670] these are not the contractors the editors asked for btw [11:33:23.0507] we asked for human typesetters who lay out books for a living, not a software license [11:33:34.0695] > <@michaelficarra:matrix.org> we asked for human typesetters who lay out books for a living, not a software license Maybe say this to the committee? [11:33:46.0609] not interested in bringing that back up [11:34:00.0734] please? I am not the right person to say so as I'm not an editor [11:34:02.0948] I want to help move this through [11:34:22.0954] OK, so our action item is to either find someone to volunteer for this two weeks per year of work, or find a contractor given that the Ecma secretariat was not able to find one [11:34:45.0327] My question about text serching was in reaction to one of the earlier drafts of the 2022 PDF where text searching didn't work [11:34:57.0053] I got quotes from FOUR typesetting companies! [11:34:57.0693] littledan: honestly I don't think we can get an action item without allen documenting his process [11:35:17.0812] if it's 95% automatable, and just needs an hour to do the edge cases, that sounds feasible for the editors to deal with [11:35:24.0083] if not, then we'd need better options [11:35:38.0850] well, he was the one to characterize it as two weeks of work, but maybe it will be less [11:36:32.0216] Let's see how this comes out but if we need support, let's schedule a call with the editors, me, and Ecma secretariat, so this doesn't keep falling on the floor [11:36:38.0511] we ended up talking past each other in email threads, i think [11:36:38.0787] right but I don't know how much that work was stuff I could automate [11:36:41.0089] every time stuff like this comes up i feel like the apparent situation is that someone got 90% of the way there and then got stuck on bureaucracy :( [11:36:47.0568] * every time stuff like this comes up i feel like the apparent situation is that someone got 90% of the way there and then got stuck on bureaucracy :( [11:37:35.0762] bakkot: well, yeah, it sounds like you're falling into the "maybe volunteer" column, so, great, we can try that and see if you want to finish that or fall back to the other column [11:37:41.0939] seems like the decision tree still maps? [11:38:07.0620] > <@devsnek:matrix.org> every time stuff like this comes up i feel like the apparent situation is that someone got 90% of the way there and then got stuck on bureaucracy :( well literally I was talking with the secretariat about this, then I took 8 months off, and now I'm back; I'd like to move this kind of thing forward [11:39:57.0314] > <@littledan:matrix.org> seems like the decision tree still maps? sure I guess I just wanted to be clear what amount of volunteering I was up for. writing automation: yes. an hour of work per year: yes. more than that: no. unclear if this would be enough [11:40:18.0378] point of order: it's pronounced eck-markup [11:41:30.0441] > <@ljharb:matrix.org> wait, so is safari's output for `String.prototype[Symbol.iterator].toString()` compliant? (starts with `function [Symbol.iterator]() {`) ljharb: this is compliant, and the relevant specification sections are https://tc39.es/ecma262/multipage/text-processing.html#sec-string.prototype-@@iterator (defines the initial "name" property as "[Symbol.iterator]"), https://tc39.es/ecma262/multipage/executable-code-and-execution-contexts.html#sec-createintrinsics and https://tc39.es/ecma262/multipage/ecmascript-standard-built-in-objects.html#sec-ecmascript-standard-built-in-objects (describes use of that name in CreateBuiltinFunction arguments), https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-createbuiltinfunction and https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-setfunctionname (uses those arguments to set [[InitialName]] and the "name" property to "[Symbol.iterator]"), and https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-function.prototype.tostring (requires that the substring of the output matched by nonterminals between `function` and `(` equals the value in [[InitialName]]—i.e., "[Symbol.iterator]"). [11:43:05.0740] proposal so delayed that saying chakracore was relevant [11:43:07.0275] > <@bakkot:matrix.org> sure I guess I just wanted to be clear what amount of volunteering I was up for. writing automation: yes. an hour of work per year: yes. more than that: no. unclear if this would be enough Did the conclusion that I stated map to what you're saying? [11:43:13.0158] littledan: yup, thanks [11:52:10.0314] do we have any registered symbols currently? [11:52:12.0579] I think no? [11:52:37.0120] FrankYFTang has had his hand raised in Google Meet for a while, but he might not be aware of the TCQ queue? [11:53:06.0141] Wait never mind, he’s on it. [11:57:04.0847] bakkot: we do not, but it's not observable anyway AFAIK [11:57:15.0192] * bakkot: we do not, but it's not observable anyway AFAIK [11:57:46.0176] well it would be observable in that you could `Symbol.keyFor` something from the spec, but otherwise yeah [11:58:07.0189] (or do `Symbol.for(x)` and get a thing from the spec, equivalently) [11:58:27.0912] hm, turning this around actually, I wonder if we could make the existing well-known symbols be registered [11:58:33.0450] probably, right? [11:59:09.0707] though Ashley Claymore 's concern is valid [11:59:22.0167] what implications would this have for weakmap keys i wonder [11:59:27.0357] * though Ashley Claymore 's concern is valid [11:59:34.0605] Was anyone proposing that we make more use of Symbol.for? [11:59:50.0564] `Symbol.for` does not provide such a signal, but you're right that `Symbol.keyFor` would [11:59:51.0395] I had understood that to be markm's proposal? [11:59:59.0373] I see [12:00:23.0223] Richard Gibson: doesn't it? `Symbol.for(str) === thingFromSpec` would become true for some `str` [12:00:46.0795] only if `thingFromSpec` were also reachable in some other way [12:00:51.0061] Yeah I share the concerns that others have raised that this causes forward compatibility risk [12:01:16.0760] the `symbol.for` space is just another shared global namespace [12:01:24.0341] not totally clear to me why we thought it was good to add more of those [12:01:30.0834] I think "web reality" is not well-defined when browsers disagree, but yes going with the majority is good [13:11:36.0679] yeah that presentation was nice and thorough [13:17:39.0170] for the notes, who is the spidermonkey person? [13:17:47.0848] oh dlm apparently, nvm [13:34:02.0674] what's the type of the result of `d.total`? [13:34:06.0028] number or bigint? [13:34:12.0074] because if it's bigint I don't like Infinity here [13:34:56.0437] number [13:35:11.0040] ok good [13:36:27.0452] should there be a way to get a total (that can not have a fractional part) as a bigint? [13:39:17.0458] mostly I'm thinking about long durations and nanoseconds but frankly I'm not super worried about it [13:39:20.0549] if it comes up we can add it later [13:39:27.0711] yeah that's what I was wondering [13:41:35.0063] serenityos is fully implemented IIUC [13:41:38.0670] cc littledan [13:42:05.0374] those people are so impressive [13:42:31.0326] oh yeah there are definitely more normative changes to Temporal yet to come but [13:42:43.0562] that's not really necessary to discuss right here haha [13:42:59.0940] > <@littledan:matrix.org> those people are so impressive I'd hoped to get invited by this one, but it was too close to June. [13:49:45.0253] Regarding the current discussion: The US tried year-round DST in 1973. It lasted less than a year before getting repealed. [13:50:19.0954] So the rules will just keep changing… [13:50:50.0279] dunno if philip is in the chat, but if so, can you capture the exact list of what we got consensus on in the notes? [13:50:56.0347] certainly [13:51:00.0245] I don't want to say "everything presented" because the presentation is ephemeral [13:51:00.0886] thanks [13:58:42.0421] added [14:09:56.0035] I don't see what the motivation to not reject unrecognised strings is [14:10:01.0071] like, who wants that? [14:10:33.0107] yeah seems like that shouldn't have been done [14:10:54.0984] it's because it was originally a boolean [14:10:58.0180] and so it just used ToBoolean [14:11:02.0379] and now they're trying to expand the space [14:11:09.0086] and it turns out some people are already passing strings [14:11:13.0900] so I guess the alternative would be to give up on this property and make a new one [14:11:15.0413] so you gotta not break them [14:11:22.0621] yeah [14:11:30.0070] I'm fine with either approach [14:11:49.0372] keep that a boolean, add something that provides better representation [14:12:48.0206] uhh what was said by ross? [14:12:50.0765] oops [14:12:50.0958] i did not hear it at all [14:12:52.0561] was that captured in the notes? it was very quiet [14:12:53.0086] sorry [14:13:05.0422] oh he did not have a mic [14:13:14.0906] Yusuke thanked Shane for the proposal [14:13:19.0124] I can say it again if needed but technically I didn't need to speak [14:14:05.0289] rkirsling: maybe just add it manually to the notes [14:14:52.0522] Kevin kindly did so for me 😅 [14:15:04.0014] Yep just looked it up! [14:19:55.0233] yeah that last argument was quite strong, I think [14:22:15.0270] resume at 14:32 [14:22:33.0326] I'll mute elastigirl [14:22:52.0001] ill head off for the day, cheers folks [14:34:03.0549] For useGrouping, did "true" and true used to resolve to different options before v3? [14:34:22.0895] I see now "true" -> "auto", and true -> "always" [14:40:43.0356] can elastigirl mute when others are speaking? we are getting feedback on the call [14:40:44.0905] The symbol approach feels a lot like https://esfx.js.org/esfx/api/collection-core/readonlycollection-interface.html#_esfx_collection_core_ReadonlyCollection_interface, so I like it. [14:41:44.0571] > <@michaelficarra:matrix.org> can elastigirl mute when others are speaking? we are getting feedback on the call it's hard to do this when we have an in-room presenter [14:42:17.0879] that is so much better, thank you [14:45:28.0785] it requires me to stand at the podium and predict transitions well [14:46:14.0569] Is the presenter able to mute/unmute themself at the podium? [14:46:51.0004] yes - i can encourage more use of the podium for that purpose [14:46:55.0563] is the echo still there? [14:47:23.0486] No echo right now. [14:47:26.0052] (but it also transfers the burden to the presenter, which is a bit of an impediment for an active presenter) [14:47:32.0214] …There is an echo now when WH talks. [14:47:34.0549] * …There is an echo now when WH talks. [14:47:34.0828] i turned down the in-room volume [14:48:17.0303] what about now? volume is lowest feasible [14:48:45.0682] > <@robpalme:matrix.org> (but it also transfers the burden to the presenter, which is a bit of an impediment for an active presenter) The presenter is more able to determine when they are about to speak, however. 🤷 [14:48:51.0557] There was still an echo just now. [14:49:23.0321] the mute is for the whole room, so the presenter needs to guess for local speakers [14:49:47.0906] i will enforce this is remote folk really need this [14:49:48.0292] I was able to understand Philip despite the echo, so that may have helped a bit. [14:50:00.0311] still bad with waldermar? [14:50:10.0827] it's definitely noticeable [14:50:32.0721] It's unfortunate the podium mic doesn't have a self-mute. [14:51:23.0109] I don’t hear an echo with WH at all anymore. [14:51:38.0360] …Well, sometimes I slightly hear one. [14:51:39.0078] It could be the table mics echoing too [14:51:40.0533] * …Well, sometimes I slightly hear one. [14:51:57.0066] the mute is for the whole room, all or nothing, Rob is diligently manning the mute booth. [14:51:59.0199] Is it working? [14:52:03.0908] Rob is currently switching [14:52:24.0605] Looks like we have less complaints with active rob mixing [14:52:42.0544] Do we need `@@setHas`/`@@setSize` or do we need `@@keysIterator`? [14:53:33.0633] > <@rricard:mozilla.org> Looks like we have less complaints with active rob mixing This sounds like a big hassle for him, maybe not sustainable in the long run; in the meantime, thank you, Rob. [14:54:07.0295] Alternatively, `intersection` could be generic and merely require the presence of `size`, `has`, `keys`. [14:54:18.0663] * Alternatively, `intersection` could be generic and merely require the presence of `size`, `has`, `keys`. [14:55:20.0754] (or `size`, `has`, `entries`) [14:56:48.0236] I kinda really like this idea [14:59:35.0634] I think the idea was more like: why can't we ask the argument to convert itself to a set? [14:59:41.0965] for sets, they would just return themselves [14:59:44.0986] yeah [14:59:56.0065] it seems like adding all of these extra methods is a bit overkill [15:00:16.0668] like i dont see how a method is gonna make this any more efficient in the case that the arg is an array [15:00:17.0369] Devin Rousso: to be clear, they are not new methods, just aliases of the existing built-ins [15:00:27.0751] Michael Ficarra: the `arg.has` i mean [15:00:29.0124] DRO: I mispasted the q you asked ont ça in the notes [15:00:36.0796] Can you please restate it here? [15:00:46.0119] Yeah, this whole proposal seems like overkill; I'd kinda prefer that we just don't try to be generic in terms of permitting an argument which does not have [[SetData]] (but maybe we rejected that in the past?) [15:00:47.0308] * Michael Ficarra: the `arg.has` i mean [15:00:55.0253] (Sorry for the bad autocorrect) [15:01:07.0411] Robin Ricard: it was something along the lines of "why cant we just convert the `arg` to a `Set`?" [15:01:13.0498] I'm fine with it going forward in this state but it's not my preference [15:01:14.0523] Thanks [15:02:03.0768] littledan: we talked about reaching into internal slots vs calling public methods at the last meeting (for 2 hours) [15:02:05.0021] > <@littledan:matrix.org> Yeah, this whole proposal seems like overkill; I'd kinda prefer that we just don't try to be generic in terms of permitting an argument which does not have [[SetData]] (but maybe we rejected that in the past?) I've written custom set implementations that could in theory work fine with this assuming a generic enough implementation of `intersection`. [15:02:27.0958] what was the conclusion? [15:02:40.0236] sorry will check notes [15:02:43.0790] slots on receiver, methods on arguments, iirc (i think it's the first slide also) [15:02:54.0042] * slots on receiver, methods on arguments, iirc (i think it's the first slide also) [15:03:10.0974] but, maybe it sounded easier in the abstract, and now it turns out to be complicated? [15:04:13.0119] in what scenario would something like `arg.has` not be worse performance than creating a `Set` from the `arg` (not including if it already is one)? [15:04:24.0433] littledan: notes here: https://github.com/tc39/notes/blob/main/meetings/2022-03/mar-31.md#extending-built-ins [15:04:44.0202] "already is a set" is the problem, because you can't do an internal slot check on a Proxy around a Set. meaning, if you pass in a proxy to a builtin Set, the performance of `.has` would be *much* better [15:04:49.0842] littledan: no, I think it's actually what we want to do [15:05:02.0296] > <@dcrousso:matrix.org> in what scenario would something like `arg.has` not be worse performance than creating a `Set` from the `arg` (not including if it already is one)? * "already is a set" is the problem, because you can't do an internal slot check on a Proxy around a Set. meaning, if you pass in a proxy to a builtin Set, the performance of `.has` would be *much* better [15:05:26.0890] ljharb: ah i see [15:05:43.0808] hence, slots only on receiver, not arguments, so that you can pass a Proxy if you want [15:05:53.0596] it just seems like we're effectively saying to developers "we should have a `Array.prototype.has = Array.prototype.includes` so that you can use it here too" [15:05:53.0825] oh, I see, this was in March, that's why I don't remember it [15:05:55.0544] but, slots on receiver so you can maximize perf and minimize observable lookups [15:06:03.0897] * but, slots on receiver so you can maximize perf and minimize observable lookups [15:06:21.0286] (The conceptual parallel between Sets and Maps is a very important point.) [15:07:18.0182] https://github.com/tc39/notes/blob/main/meetings/2022-03/mar-31.md#extending-built-ins [15:09:40.0881] I guess no conclusion was recorded [15:09:47.0560] there are echos [15:09:47.0956] there is echo [15:09:50.0073] There is still echo. [15:12:02.0756] I'd note that a lot of the previous discussion was with Shu; he's out today, so it's probably worth discussing this with him offline if you haven't done so already [15:12:28.0970] I'm not opposed to symbols for this, since symbols often are to JS what interfaces are to statically typed languages. They convey a very specific intent and avoid collisions with same-named methods with different intentions. To Devin Rousso 's point, we could potentially have a `@@toSet` symbol that returns a `{ size, has(), @@iterator() }` that a `Set` could just `return this`. [15:13:07.0308] i think my overarching point is that it seems like a *lot* of work just to make a `Proxy` of a `Set` work 😕 [15:13:31.0323] we're talking about symbols just for the argument, not the receiver, right? [15:13:34.0616] which id imagine is probably one of (if not the) least common arguments that will be used for this [15:14:48.0207] If I were to pass a Proxy for a `Set` to `intersection`, I would *definitely* expect it to go through the proxy's `size`, `has`, etc. rather than work directly against `[[SetData]]`. [15:14:55.0100] part of me also is wondering why we dont just require that the arg actually be a `Set` [15:15:22.0649] given how much some delegates dislike extending builtins [15:15:46.0152] I mentioned above, I have classes like `HashSet` and `SortedSet` that do not inherit from `Set`, but could easily participate in `Set.prototype.intersection` [15:15:55.0419] or if not a `Set` then maybe we just require that the arg has a `has` method [15:16:06.0148] * or if not a `Set` then maybe we just require that the arg has a `has` method [15:16:30.0560] rbuckton: Ah OK I see [15:17:07.0630] rbuckton: IMO as long as your `HashSet`/`SortedSet` has a `has` then i would kinda expect that that'd be enough (at least for `intersection`) [15:17:16.0401] * rbuckton: IMO as long as your `HashSet`/`SortedSet` has a `has` then i would kinda expect that that'd be enough (at least for `intersection`) [15:17:47.0264] I wouldn't be opposed to adding either a `@@setSize`/`@@setHas` or `@@toSet` to those types. In fact, they already use the `ReadonlyCollection.size`/`ReadonlyCollection.has` symbols I publish in `@esfx/collection-core`. [15:18:08.0182] * I wouldn't be opposed to adding either a `@@setSize`/`@@setHas` or `@@toSet` to those types. In fact, they already use the `ReadonlyCollection.size`/`ReadonlyCollection.has` symbols I publish in `@esfx/collection-core`. [15:21:04.0415] > <@dcrousso:matrix.org> part of me also is wondering why we dont just require that the arg actually be a `Set` That's actually the opposite of what we would do based on our recommendation to not extend builti-ins. Our recommendation in lieu of that is to build something (possibly a wrapper) that provides the Set API. For that to work, we need to *not* require that the argument is a Set. [15:21:31.0341] that's fair [15:22:27.0961] OK, thanks for recapping the motivation [15:24:04.0768] littledan: yeah I think the powerful takeaway from the extending built-ins discussion is that language users don't "own" the internal slots for built-ins, we do [15:24:36.0427] so if they want to like gate access to those slots, it is inappropriate to extend/override methods, because we may provide additional access to those slots in the future through new methods [15:25:09.0045] instead, they should build something that wraps the built-in and expose access to the built-in with their desired lmiitation/extension [15:25:22.0819] right I was not picturing that we'd provide extensibility through subclassing, but rather that we just don't provide any compatibility with different types for arguments at all [15:25:29.0002] again, can we just make the well-known symbols registered [15:25:30.0933] i like that option [15:25:40.0345] give them long names no one is going to have used, maybe [15:26:04.0427] HMAC their name with a secret only known to TC39 [15:26:23.0661] we also could've just used longer strings for these names, like `"__iterator__"`... [15:26:46.0924] that seems quite python-y [15:28:23.0448] `@@iterator`, reify the spec thing [15:31:12.0420] If we use a stringy-enum, I'd like to find a term other than "unique". [15:32:11.0781] I don't know how nobody in the ES2015 timeframe noticed the incredible irony of sticking the well-known symbols on Symbol, creating a string-based namespace [15:32:28.0296] TS uses `unique symbol` in type-space to denote a Symbol tied to a declaration for static typing purposes. It wouldn't affect runtime, but would be *very* confusing for our users. [15:32:41.0951] I think everyone just wanted ES2015 to ship despite it not being perfect (understandable) [15:33:15.0646] it has a lot of things that were understood at the time to be a compromise among committee members, and a lot of things which were only discovered to be problematic later (e.g., during implementation, but that was considered too late back then) [15:34:09.0361] Symbols were initially supposed to be a path to private state! But then people felt like there need to be reflective interfaces for them... [15:34:11.0954] it was like it was rushed out at the end [15:34:34.0906] yeah, I think so, but it's easy for us to say that, as we weren't in the debates for four years [15:34:39.0614] * yeah, I think so, but it's easy for us to say that, as we weren't in the debates for four years [15:34:43.0218] I agree with ljharb that these APIs are more ergonomic than the mechanisms mark wants, but I don't think this comes up often enough for it to be worth optimizing for ergonomics very hard [15:34:51.0241] yeah, we only saw the last like 3 or 4 meetings of ES2015 [15:35:12.0355] in my very first TC39 meeting, they voted to finalize ES2015 [15:36:08.0655] I never felt that was the case, and thought that "private symbols" was supposed to be what you are talking about. I always looked at symbols as a means to emulate `interface` in static languages so as to avoid collisions due to the same name/different intent. [15:37:20.0620] > <@littledan:matrix.org> Symbols were initially supposed to be a path to private state! But then people felt like there need to be reflective interfaces for them... * I never felt that was the case, and thought that "private symbols" was supposed to be what you are talking about. I always looked at symbols as a means to emulate `interface` in static languages so as to avoid collisions due to the same name/different intent. [15:37:20.0620] Robin Ricard: you're sharing your screen [15:38:01.0305] > <@rbuckton:matrix.org> I never felt that was the case, and thought that "private symbols" was supposed to be what you are talking about. I always looked at symbols as a means to emulate `interface` in static languages so as to avoid collisions due to the same name/different intent. Yes, both of these [15:38:13.0333] I didn't say that that was the *only* intention of symbols, but it was also a major one [15:38:52.0346] The return override trick is a beautiful solution to how custom elements can use private fields! [15:38:54.0111] Robin Ricard: still sharing [15:39:46.0195] thnaks [15:43:48.0699] wait so if you can add private fields to fozen/preventExtensions objects, how is that not a communications channel nightmare? [15:44:03.0938] erights: ^ [15:44:22.0423] Mark’s not in this channel. I’ll forward. [15:44:50.0079] you can also put frozen objects in a WeakMap. it's the same thing [15:45:04.0536] if you have access to a private field, you already can have a side channel [15:45:13.0693] you can prevent the communication of the private field itself [15:45:14.0529] exactly [15:45:25.0977] the point is that you can't hand the object to someone else and have them get access to the private field, or the weakmap, unless you give them the weakmap (or a lens around the field) [15:45:36.0043] ie having the object doesn't grant any capabilities unless you also have the "other piece" [15:45:48.0004] * ie having the object doesn't grant any capabilities unless you also have the "other piece" [15:46:25.0251] okay that makes sense [15:50:45.0478] didn't we have explicit consensus about "legacy" items being the new way annex b happens [15:51:27.0687] i really don't want to argue more about annex b lol [15:52:00.0807] snek: no, Legacy just means icky [15:52:23.0506] normative optional + legacy rather [15:52:27.0721] https://tc39.es/ecma262/#sec-conformance [15:52:37.0696] except this is a host hook, so normative optional doesn't really matter [15:54:36.0930] "I have to skip past this unrelated part" is not the same as "I have to know to look in Annex B any time I read anything" [15:54:47.0685] one is WAY MORE burdensome [15:54:56.0400] this is legitimately annoying me i'm gonna go burn down my github notifications [15:56:19.0546] > <@michaelficarra:matrix.org> one is WAY MORE burdensome Though we do have a bunch of "NOTE This section is extended by Annex B..." throughout the spec, at least. [15:57:13.0408] also, is this not 100% an editorial concern? shouldn't we trust the editors to organise the spec in a way that benefits the considered readers the most? [15:58:22.0983] if anyone is not aware, the editor group spends a *lot* of time considering how the different readers of the spec will be impacted by even very minor wording/presentation things [15:58:46.0907] and we consider all sorts of readers [15:58:54.0452] Note that much of Annex B is shipped outside of browsers (but this probably doesn't need to be) [16:19:35.0562] > <@dcrousso:matrix.org> or if not a `Set` then maybe we just require that the arg has a `has` method sorry, I should have made the constraints here clearer: - we want to accept things which are not actually Sets for reasons discussed at length in the previous meeting, most significantly that we consider the only good way to modify the behavior of a Set to use composition, rather than inheritance, which means Set-like things will come up in real life - just invoking the string-named `has` directly runs into this problem with Map where doing that will work _only if the map is larger than the set_, which is _extremely_ painful behavior for an API to have [16:20:11.0289] > <@dcrousso:matrix.org> or if not a `Set` then maybe we just require that the arg has a `has` method * sorry, I should have made the constraints here clearer: - we want to accept things which are not actually Sets for reasons discussed at length in the previous meeting, most significantly that we consider the only good way to modify the behavior of a Set to use composition, rather than inheritance, which means Set-like things will come up in real life - just invoking the string-named `has` directly runs into this problem with Map where doing that will work as if you'd passed the Set of the map's keys _only if the map is larger than the set_, which is _extremely_ painful behavior for an API to have [16:22:41.0953] ``` interface Setish { hasKey(k): boolean; size: number; keys(): Iterator; } ``` [16:23:15.0063] > <@bakkot:matrix.org> sorry, I should have made the constraints here clearer: > > - we want to accept things which are not actually Sets for reasons discussed at length in the previous meeting, most significantly that we consider the only good way to modify the behavior of a Set to use composition, rather than inheritance, which means Set-like things will come up in real life > - just invoking the string-named `has` directly runs into this problem with Map where doing that will work as if you'd passed the Set of the map's keys _only if the map is larger than the set_, which is _extremely_ painful behavior for an API to have The map issue is related to iterating over its entries by default, as opposed to explicitly mapping over `.keys`. Your point about incompatible `has` and `keys` stands, but is just as applicable to `has` and `size` [16:23:29.0568] * sorry, I should have made the constraints here clearer: - we want to accept things which are not actually Sets for reasons discussed at length in the previous meeting, most significantly that we consider the only good way to modify the behavior of a Set to use composition, rather than inheritance, which means Set-like things will come up in real life - just invoking the string-named `has` directly (and using `Symbol.iterator`) runs into this problem with Map where doing that will work as if you'd passed the Set of the map's keys _only if the map is larger than the set_, which is _extremely_ painful behavior for an API to have - using `has` and `keys` (rather than `Symbol.iterator`) happens to work ok for maps, but one could have a List data structure which has a `has` method which does list membership but for which `keys` gave indices as it does for Array [16:24:43.0858] so size might also need some namespacing? [16:25:02.0976] rbuckton: yeah, true; the fundamental thing is that you need these methods to have a specific relationship to each other, and that relationship is not obvious for {string/well-known-symbol}-named methods [16:25:23.0113] It's unfortunate you can't intersect with an array, which instead has `length` and `includes`, and whose `keys` are indices, but you have to draw the line somewhere I suppose. [16:25:37.0993] > <@aclaymore:matrix.org> ``` > interface Setish { > hasKey(k): boolean; > size: number; > keys(): Iterator; > } > ``` we _could_ do something like that but that seems way worse than symbols [16:26:01.0150] > <@rbuckton:matrix.org> It's unfortunate you can't intersect with an array, which instead has `length` and `includes`, and whose `keys` are indices, but you have to draw the line somewhere I suppose. honestly I'm OK with that, since using `includes` would make it O(n^2), which would be very surprising [16:26:40.0782] This was why I suggested putting the whole protocol behind one symbol, so that serves as a single namespace for everything. ``` interface Setish { [Symbol.Setish](): { size: number: has(v): boolean; values(): Iterator; } } Set.prototype[Symbol.Setish] = function() { return this; } ``` [16:26:45.0936] I'm considering the possibility of falling back to `Symbol.iterator` in `intersection` in the case that the argument lacks `has`/`setHas`; not sure how I feel about that yet [16:26:55.0720] * This was why I suggested putting the whole protocol behind one symbol, so that serves as a single namespace for everything. ``` interface Setish { [Symbol.Setish](): { size: number: has(v): boolean; values(): Iterator; } } Set.prototype[Symbol.Setish] = function() { return this; } ``` [16:27:27.0125] > <@aclaymore:matrix.org> This was why I suggested putting the whole protocol behind one symbol, so that serves as a single namespace for everything. > > ``` > interface Setish { > [Symbol.Setish](): { > size: number: > has(v): boolean; > values(): Iterator; > } > } > > Set.prototype[Symbol.Setish] = function() { return this; } > ``` yeah; this implies an extra property access, though, and I don't see any benefit over just having more symbol-named methods (though maybe I am missing what the benefit is?) [16:27:46.0373] someone may have asked this but we have a pattern of keys/values/items on things, can we just always ask for keys? [16:27:54.0820] We could have symbols to produce a "view" over an object, ie, `@@setView()` returns a `Set`-like representation. [16:28:16.0083] Then even an `Array` could produce a set-like view [16:28:42.0265] again, making Array set-like makes intersection O(n^2), which seems bad [16:28:43.0461] Or at least, a read-only representation. [16:28:44.0441] cost is one single prop access per method call (seems low). Benefit is the protocol itself can be string based which is nicer to type. And also that it's low impact to implement the interface (only need one unique symbol) [16:29:10.0844] > <@bakkot:matrix.org> yeah; this implies an extra property access, though, and I don't see any benefit over just having more symbol-named methods (though maybe I am missing what the benefit is?) * cost is one single prop access per method call (seems low). Benefit is the protocol itself can be string based which is nicer to type. And also that it's low impact to implement the interface (only need one unique symbol) [16:29:18.0033] yeah but it means the protocol is a lot more complicated; for anything for which it was not just `return this`; it would be a lot more work overall [16:29:40.0768] > <@bakkot:matrix.org> again, making Array set-like makes intersection O(n^2), which seems bad And if you need that, you'd just be doing `set.intersection(new Set(ar))` anyways [16:30:16.0995] and this is not something we expect people to be doing very often - at most once per new set-like you implement, which, I don't do that very frequently. so not something I think it's very important to optimize for ergonomics very much [16:31:00.0993] > <@bakkot:matrix.org> yeah but it means the protocol is a lot more complicated; for anything for which it was not just `return this`; it would be a lot more work overall only more complicated for things that want to implement multiple conflicting protocols (because they can't `return this`). The other approaches don't support being able to support multiple conflicting protocols at all. [16:31:59.0532] if the protocol is entirely symbol-based, then there's no such thing as a conflicting protocol? [16:32:00.0202] that claim confuses me [16:32:41.0105] only if all the symbols are unique to that protocol. e.g. don't use something generic like `Symbol.iterator` [16:32:42.0035] and to be precise, your proposal is more complicated for anything which wants to use `has` in a way that is inconsistent with how the Set protocol uses it, which is not the same as "implementing multiple protocols" [16:33:19.0092] yes, and as I said, if we think that people might want to do iteration in multiple inconsistent ways then we would not use Symbol.iterator in the set protocol [16:33:35.0135] we would instead only use set-specific symbols [16:33:40.0488] * we would instead only use set-specific symbols [16:33:48.0174] (if we aren't concerned about that, of course, it's not relevant) [16:34:20.0826] I guess what I'm trying to get but also avoid is: `Symbol(setHas)` `Symbol(setSize)` `Symbol(setValues)` [16:34:34.0636] right, and, why are you trying to avoid that? [16:34:47.0485] that's what I'm missing [16:34:57.0761] its a lot of symbols ¯\_(ツ)_/¯ [16:35:04.0748] * its a lot of symbols ¯\\_(ツ)\_/¯ [16:35:17.0329] so it is but I am still not seeing the problem [16:35:35.0715] ha! fair, it's not really a problem. But a subjective thing [16:36:35.0606] I think symbols are good and should be encouraged, and intermediate objects are bad and should be discouraged, is my general feeling [16:37:04.0441] incidentally are people still hanging around the office somewhere? [16:37:37.0414] I'm somewhat partial to parts of Michael Ficarra's `protocol` proposal, which provides an easy way to group related symbols by a namespace. [16:37:49.0411] yeah, I was talking to him about this [16:38:09.0637] had we settled on the choice of using symbol-named things, I was going to propose that we put these symbols under `Set.protocol` [16:38:16.0618] i feel like I miss understood that proposal, as it didn't seem to namespace the protocols? [16:38:28.0683] so `Set.protocol.has = Symbol()`, etc [16:38:53.0231] Ashley Claymore: the protocols themselves are just values which hold symbols [16:39:10.0937] There were parts of that proposal that seemed very disconnected, but I emulated the namespacing aspect in a lot of my `@esfx/*` packages. [16:39:57.0763] My reading of the README was that the fields are symbols but the methods were strings [16:40:19.0354] nope [16:40:33.0536] ``` protocol ToString { tag; toString() { return `[object ${this[ToString.tag]}]`; } } Object.prototype[ToString.tag] = 'Object'; Protocol.implement(Object, ToString); ``` [16:40:38.0933] cc Michael Ficarra ^ I told you this was misleading [16:40:55.0952] Ashley Claymore: yes, that's what the readme says, but the readme is misleading on this point [16:41:00.0269] How do I call the `toString` [16:41:12.0274] please just ignore that example [16:41:14.0366] that is a bad example [16:41:24.0013] will do :) [16:41:52.0628] I didn't like the bit of declaring both named symbols *and* non-symbol methods together, it was very confusing. [16:42:07.0533] the proposal it doesn't allow you to declare non-symbol methods [16:42:10.0289] only to require they exist [16:42:27.0943] Would be nice if the README had an example of calling the protocols too. I think that's what I'm missing [16:42:33.0083] See `toString` in the example above. [16:42:47.0565] the `toString` example is bad [16:42:49.0911] it is bad and wrong [16:42:51.0371] please ignore it [16:42:54.0546] Michael Ficarra: please fix it [16:43:49.0532] If it's *just* Namespaced symbols, I like it because I can attach type info to it in TS. Mixing in implementations in the same namespace is confusing. [16:45:37.0886] I'd be fine with a version that let you specify a *default* implementation of a `symbol` method, but the last version I saw seemed like it was also trying to handle mixins as well 2022-07-21 [17:02:14.0010] a downside of using a set-specific iterator method is that `union` _only_ needs iteration, and so it would maybe be nice if `set.union(array)` worked. but it also seems bad for `set.union` and `set.intersection` to iterate with different methods [17:02:50.0834] I guess I would not terribly mind giving up on `set.union(array)` working, though [17:18:47.0927] There are other approaches to computing a set intersection that don't depend on calling `has` on `arg`, at the expense of space. [18:51:53.0630] ljharb "petty" wasn’t the right word today, sorry. [18:55:55.0173] I’m still not sure what the right word is. It seemed like you’re saying don’t worry about the limitation to web browsers, it’s analogous to a sign that reads "no stealing (except thieves)". That just doesn’t seem to me like a good defense for the sign. But, again, at Agoric we’re satisfied that we can point to the meeting notes if it comes up again. [18:56:50.0365] One thing is certain, though: I picked the wrong word! [19:40:08.0267] tbh that’s a fine analogy if we can ignore the inherent negative connotation. someone is welcome to steal if they’re content with the associated label and all it implies. [19:40:48.0415] anyones welcome to violate any spec they want as well, as long as they’re willing to give up on the label of complying with it ¯\\\_(ツ)_/¯ [20:50:45.0312] does anyone know if the meetup today was recorded? [22:23:24.0137] The gmeet had a “recording” status on it, so possibly yes [05:40:14.0961] > <@aclaymore:matrix.org> The gmeet had a “recording” status on it, so possibly yes the plenary was recorded? [06:13:15.0857] Sorry for the confusion. We were talking about the post plenary meet-up. [09:00:50.0661] Keep seeing "deiter updates" and thinking, who's Deiter? [09:04:10.0337] De-iterator [09:04:33.0637] From HE Shi-Jun (hax) [09:06:00.0814] Ashley Claymore: rbuckton: the best explainer for protocols right now is the presentation at https://docs.google.com/presentation/d/1HnxJl4Iodf3I23e-ZDkw4F1LEkMRGUBFq6xxR0a9a_k/edit#slide=id.g3e3a1a53c0_0_0 [09:06:14.0497] I'll work on providing better detailed documentation soon as I prepare for stage 2 [09:06:50.0673] dieter: https://www.youtube.com/watch?v=rZMoGyr1BFU [09:37:00.0212] > <@rkirsling:matrix.org> Keep seeing "deiter updates" and thinking, who's Deiter? Because double-ended queue is shorted to "deque", I use "deiter" as the abbr for double-ended iterator 😅 [10:07:48.0743] what is `.indexed()`? [10:07:59.0246] oh i see [10:10:34.0597] for those reading Matrix later: https://github.com/tc39/proposal-iterator-helpers#indexed [10:12:15.0282] i wish we could just call it enumerate like every other language :( [10:13:24.0293] indexed is better than asIndexedPairs though [10:13:29.0208] so i'm not complaining too much [10:13:55.0944] otoh i would not have needed to ask the question if it was named `asIndexedPairs`! [10:14:45.0076] Call and raise `toIndexEntries` [10:15:13.0571] I have no strong opinion but I'd be fine with including `Iterator.prototype.flat` [10:15:29.0578] (Never mind my bikesheddery joy. I’m fine with `indexed`.) [10:15:32.0325] since it does make sense, as explained [10:16:25.0948] No opinions from me either [10:16:35.0870] * No opinions from me either [10:18:13.0507] oh I thought that flat/flatMap for iterator helpers was about iterators that yield arrays and such [10:18:34.0045] I can definitely see how flat is difficult if we want it to be for iterators of iterators [10:18:55.0372] iterators that yield iterables, which includes arrays [10:18:58.0690] * iterators that yield iterables, which includes arrays [10:18:59.0153] right [10:19:06.0369] this explanation makes me want to omit flat, yes [10:20:36.0801] Interesting. C#'s linq/Enumerable provides an index, which is quite useful [10:23:37.0873] I found the argument compelling that you should use `indexed` and not rely on the `index` arg of `map` callbacks &c. [10:33:15.0054] I guess I am not super opposed to passing `index`. I am worried people will get confused but also some people will definitely get utility from it, so /shrug [10:33:45.0855] i am opposed to it [10:34:01.0540] for same reasons as mficarra? [10:34:04.0170] the original reasoning is that we explicitly force you to consider when you are introducing the counter which starts from 0 [10:34:07.0456] i don't really see the harm [10:34:16.0640] why is that a good thing to force? [10:34:34.0590] My concern about dropping `index` is theefold: 1. Migrating code that uses `Array.prototype.map` to `Iterator.prototype.map` requires reaching for something new and refactoring your code to accept an array pair. 2. Reusing existing named functions as callbacks requires them to either be polymorphic or the need to wrap the callback in an arrow to set the correct parameters. 3. Reaching for an index requires allocating an array pair for *every* element, as opposed to a single number passed as an extra argument. [10:35:15.0283] i think the "element, index, collection" callback parameter order is pretty ingrained [10:35:19.0080] collection obviously doesn't make sense [10:35:22.0303] but i don't see the harm in providing index [10:35:36.0079] `for-of` doesn't provide an index [10:35:39.0831] I almost never see anyone using `collection`, but frequently see folks using `index`. [10:35:40.0966] why would iterator helpers do so? [10:35:55.0224] for-of doesn't take a callback that's called per iteration [10:36:01.0780] what does that have to do with this? [10:36:11.0183] like the iterator protocol overall doesn't have a concept of indexes [10:36:21.0496] it just has next → value/done (ignoring return/throw) [10:36:26.0388] * it just has next → value/done (ignoring return/throw) [10:36:35.0538] the users of this API won't be thinking of this in terms of the iterator protocol [10:36:37.0733] yet 😉 [10:36:43.0048] `for..of` is fairly limited in any respect. [10:36:44.0469] they will be thinking of this in terms of "oh a per-iteration callback" [10:36:44.0526] the classic example was what if you add a drop at the start of your iterator chain [10:36:48.0514] * the classic example was what if you add a drop at the start of your iterator chain [10:36:58.0200] arguably it's weird that you can do .drop and now the indices are different from what they would've been. OTOH I agree with Shu's intuition point. [10:37:25.0210] it's semantically weird in a narrow semanticists' way imo [10:37:39.0451] .toAsync() SGTM [10:37:48.0191] I still find I'm more likely to use an npm package over iterator helpers, and not including `index` makes this even more likely for me. [10:37:56.0733] I mean, this proposal is sort of betting against pipeline in general [10:38:48.0541] even with pipeline we'd still want lazy iterator helpers tho, no? [10:38:52.0818] * even with pipeline we'd still want lazy iterator helpers tho, no? [10:39:15.0663] yes, but we might do a function-based version if we had pipeline [10:39:19.0054] we definitely cannot go back to arguing about whether these functions should be static [10:39:22.0609] in the current example i'd only use a pipeline on the `arr.values().map(foo) |> AsyncIterator.from(%)` part [10:39:27.0474] It's not that bad... ```js arr.values().map(foo) |> AsyncIterator.from(%) |> %.filter(async x => await bar(x)) ``` [10:39:37.0398] * in the current example i'd only use a pipeline on the `arr.values().map(foo) |> AsyncIterator.from(%)` part [10:39:59.0776] topics ftw [10:40:08.0643] That said, I have `toAsync` in my own iteration library, so I'm not opposed. [10:40:25.0437] yeah I'm in favor of toAsync since we want to reinforce method chaining [10:40:46.0689] and this does have to do with pipeline not existing but that's fine; it still doesn't feel like a wart. [10:42:07.0638] If I'm working with an Iterator I almost *always* expect it to be lazy (unless I'm generating a scalar value with a reduce or toArray, etc.) [10:43:29.0431] I was slightly surprised that drop was lazy but the explanation seems fine [10:43:44.0875] eager `take` would be effectively "take and throw on the ground" [10:44:00.0621] right [10:44:37.0645] are we 100% we can't fix the override mistake? [10:45:18.0764] We are not 100% sure we can’t fix the override mistake. [10:45:27.0778] We are also not 100% sure we can. [10:45:30.0142] I think it'd take some kind of opt-in due to the compat issues we discovered [10:46:11.0424] "use flawless"; [10:49:22.0744] +1 to not imposing requirement on all new intrinsics being programmatically reachable [10:49:35.0200] With regards to the Clojure indexed functions I referred to a few minutes ago, here they are: [10:49:37.0124] https://clojuredocs.org/clojure.core/map-indexed [10:49:37.0565] https://clojuredocs.org/clojure.core/keep-indexed [10:49:55.0440] I believe the reason for this was Rich Hickey wanting to avoid unnecessary indexed-entry garbage creation. [10:50:08.0127] out of curiosity does clojure have car and cdr [10:50:10.0170] Confused by the argument order of `.zipWith`, would expect other iter to come first. [10:50:11.0679] * I believe the reason for this split (rather than a single `indexed` function) was Rich Hickey wanting to avoid unnecessary indexed-entry garbage creation. [10:50:34.0798] The argument order specified is terrible for static typing/contextual typing. [10:50:43.0294] It calls them `first` and `rest` and they work on lazy iterators. [10:50:55.0695] In fact they are the iteration primitives. [10:51:04.0781] OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers? [10:51:12.0335] * In fact they are the iteration primitives. [10:51:28.0005] > <@devsnek:matrix.org> out of curiosity does clojure have car and cdr * It calls them `first` and `next` and they work on lazy iterators. [10:51:59.0060] Very much will object to new intrinsics unreachable by transitive property walk from globalThis. [10:52:16.0800] Is `.zipWith` part of the proposal or outside the scope? [10:52:36.0487] Looks like its outside the scope currently. [10:52:36.0944] > <@apaprocki:matrix.org> OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers? which browsers? have not seen this and sounds incorrect [10:52:53.0449] * It calls them `first` and `rest` and they work on lazy iterators. [10:53:07.0661] > <@rbuckton:matrix.org> Is `.zipWith` part of the proposal or outside the scope? all the methods he just listed are outside the proposal [10:53:31.0777] I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. [10:54:12.0573] Very much would relax position if another mechanism makes all intrinsics reachable programmatically. [10:54:48.0352] > <@littledan:matrix.org> I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. Axel! [10:54:56.0850] yes I'm very happy about that [10:55:04.0946] > <@devsnek:matrix.org> which browsers? have not seen this and sounds incorrect all browsers? chromium, safari, node just from looking [10:55:54.0496] > <@apaprocki:matrix.org> OT: Is there something I'm not seeing in Annex B that makes Number.toString(-0.0) return "-0" in browsers? `-0.0` just parses to `-0`, and `Number.toString === Function.prototype.toString`, but `(-0).toString()` returns "0" for me [10:56:11.0628] I guess I'm not describing it right -- they all do it in their REPLs [10:56:15.0852] seemingly "undoing" what is spec'd [10:56:20.0096] right, that's where i'm trying it [10:56:22.0230] cannot repro [10:56:32.0083] are you by any chance on a website that might be patching stuff? [10:56:39.0963] what does `Number.prototype.toString.toString()` log out [10:56:40.0910] Hey folks I need to leave early if you have any questions please ask Dan minor [10:57:07.0599] * native code for function tostring [10:57:13.0243] * native code from function tostring [10:57:17.0463] i mean for apaprocki specifically [10:58:17.0562] No, the output of > Number(-0.0) -0 [10:58:27.0867] today littledan is going to do a debrief on the steganography note-taking trial we conducted yesterday morning. please have a read of those notes so you can form opinions on their quality. [10:58:33.0641] not Number.prototype.toString(-0.0) [10:58:44.0976] > <@shuyuguo:matrix.org> +1 to not imposing requirement on all new intrinsics being programmatically reachable I’m curious what the downside is, apart from cognitive burden upon delegates. [10:59:04.0934] > <@apaprocki:matrix.org> No, the output of > > Number(-0.0) > -0 that's normal, but that's not tostring, that's the repl being helpful and telling you its -0 [10:59:27.0076] https://gc.gy/126131365.png [10:59:40.0046] Kris Kowal: main reasoning from me is extra onus on design that has bearing on a niche use case [10:59:40.0048] yeah, so just curious whether that is just informal convention or if that's written down anywhere [11:00:00.0258] apaprocki: informal convention; debug output for values in a repl has no spec i'm aware of (unless HTML has one for browsers) [11:00:00.0890] where an intrinsic can be made reachable without extra contortion, go ahead [11:00:10.0599] otherwise nothing compelling to me to require the contortion [11:01:51.0562] i'm sure you're aware this is almost existential to the niche use case [11:01:56.0165] > <@devsnek:matrix.org> https://gc.gy/126131365.png Yeah the interesting part to me is that every REPL/console implementation just seems to special-case this in its own way. Ours was missing this extra check and outputting 0, and special-casing -0 seemed crazy. Guess it's just the way it is... [11:02:08.0866] Kris Kowal: i am [11:02:30.0902] > <@littledan:matrix.org> I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. Note here that Axel has advocated for functions on iterables rather than methods on iterators; I'd suggest the proposal champions get in touch with him to discuss further. [11:02:59.0571] Kris Kowal: and there is a good solution here as markm has pointed out: put efforts there? [11:03:02.0050] > <@apaprocki:matrix.org> Yeah the interesting part to me is that every REPL/console implementation just seems to special-case this in its own way. Ours was missing this extra check and outputting 0, and special-casing -0 seemed crazy. Guess it's just the way it is... we (nodejs) found a cool bug in v8 because of this https://github.com/v8/v8/commit/56f6a76 [11:03:05.0810] with getIntrinsics [11:03:18.0867] I'm really confused about the motivation for double-ended iterators. If it's destructuring, I think we can support `let [x, ...y, z] = a` without this, just through iterating through the rest until it ends [11:03:23.0799] > <@littledan:matrix.org> Note here that Axel has advocated for functions on iterables rather than methods on iterators; I'd suggest the proposal champions get in touch with him to discuss further. I very much share this perspective. [11:03:38.0741] (getIntrinsics remains having implementation concerns to be clear, so it's not also like it's smooth sailing) [11:03:48.0581] i would love to hear more about these [11:03:52.0904] > <@littledan:matrix.org> I'm really confused about the motivation for double-ended iterators. If it's destructuring, I think we can support `let [x, ...y, z] = a` without this, just through iterating through the rest until it ends The last slide was specifically about the performance implications of that approach. [11:04:01.0171] > <@devsnek:matrix.org> we (nodejs) found a cool bug in v8 because of this https://github.com/v8/v8/commit/56f6a76 ah subnormals... IEEE754 my old friend [11:04:27.0720] > <@shuyuguo:matrix.org> with getIntrinsics If getIntrinsics reveals all new intrinsics, then mitigating supply chain attacks remains feasible. [11:04:40.0193] how can getIntrinsics not reveal all intrinsics? [11:04:44.0031] isn't that what it does? [11:04:50.0744] that is its purpose, yes. [11:05:01.0116] that's not its purpose, but with the enumeration requirement yes, that's what it will also do. [11:05:19.0624] its primary purpose is to get a single specific known intrinsic. its secondary purpose is now to enumerate/iterate all intrinsics. [11:05:26.0496] * its primary purpose is to get a single specific known intrinsic. its secondary purpose is now to enumerate/iterate all intrinsics. [11:05:51.0598] ljharb: mainly need to audit the intrinsics that are currently _not_ kept on the NativeContext in V8, how many of those we have, how much more memory use does keeping those incur for low-memory environments (Android) [11:06:22.0117] thanks - is that something that can be investigated early enough in the stage process to avoid surprises later? [11:06:30.0585] > <@shuyuguo:matrix.org> ljharb: mainly need to audit the intrinsics that are currently _not_ kept on the NativeContext in V8, how many of those we have, how much more memory use does keeping those incur for low-memory environments (Android) * thanks - is that something that can be investigated early enough in the stage process to avoid surprises later? [11:06:38.0207] and, if unacceptable, figure out mitigation, then figure out acceptability of those mitigation techniques [11:06:44.0920] > <@shuyuguo:matrix.org> ljharb: mainly need to audit the intrinsics that are currently _not_ kept on the NativeContext in V8, how many of those we have, how much more memory use does keeping those incur for low-memory environments (Android) i have bad news about nativecontext lol, so much random stuff on there [11:06:54.0213] sure i know [11:07:17.0437] ljharb: a soft deadline would help me prioritize, depends on what timeline you want? [11:07:30.0009] > <@rbuckton:matrix.org> The last slide was specifically about the performance implications of that approach. So, yes, I get that you end up having to allocate the array a little bigger and then trim it back, but I am not convinced that this will be anything like a performance bottleneck. JS Array implementations already need to be able to handle that usage pattern somewhat efficiently. It's a lot less costly operation than the rest of the iteration protocol. [11:07:47.0052] For the hardened JavaScript use case, the qualifiers can be more specific to any intrinsics programmatically reachable from "the shared intrinsics", which we would like to cover as much as possible, but can’t for example cover Intl for other reasons. [11:07:50.0937] probably I'm missing something [11:07:52.0625] > <@shuyuguo:matrix.org> ljharb: a soft deadline would help me prioritize, depends on what timeline you want? i'm hoping to ask for stage 2 in september or november; assuming that happens, then it'd be great to have the investigation done by the end of the year so the path to stage 3 is clear [11:08:05.0858] ok [11:08:18.0406] i didn't say yes! [11:08:21.0938] i said ok, as in ack [11:08:33.0222] lol fair enough, i still appreciate the explanation and consideration [11:08:35.0406] is every other line of this slide a different font size [11:08:42.0323] I was going to ask [11:08:52.0662] is it like, a font-size-based justification algorithm? [11:08:59.0078] it's trippy [11:09:15.0326] > <@devsnek:matrix.org> is every other line of this slide a different font size Hax does this for conference talks too--it's actually a pretty nice way to maintain visual engagement in those cases [11:09:39.0365] looks especially nice with a slide with a few ideographic characters totally filling the screen [11:10:54.0029] but it was a paragraph of text [11:12:17.0558] like, it's a really unpleasant fun-house mirror effect [11:21:36.0007] in most languages they meet in the middle right? [11:21:41.0190] I *just* got how you would implement Iterator.prototype.take to be eager and omg no it is not eager [11:21:58.0804] lmao [11:21:59.0916] lol that's such a bad idea I couldn't even fathom it [11:22:32.0718] takeWithCache [11:22:49.0433] might as well `toArray`/`slice` at that point [11:23:27.0302] technically all of the iterator helpers could be implemented in this way [11:23:51.0619] completely defeating the point of iterators, sure [11:25:28.0143] Can we have a 5-minute extension to go through the queue [11:25:30.0744] i think it's important for us to get to dan's queue item [11:25:38.0652] direct feedback on this question hax wants feedback on [11:27:26.0251] ok but implementations would definitely otpimize this for built-ins [11:27:45.0182] and it would be kind of annoying that once you have a userland wrapper of the built-in it suddenly gets many orders of magnitude slower [11:28:55.0236] also I do kind of want to get the last thing from sets sometimes [11:29:16.0682] i often want the nth things from sets [11:33:28.0707] why do you think sets are randomly accessible [11:33:32.0003] unfortunately they actually are [11:33:41.0578] but i don't want to codify that in practice [11:34:53.0660] are there any practical ordered collection implementations that are not randomly accessible [11:35:02.0423] (i ask this seriously, i don't know the answer) [11:35:35.0551] me neither [11:35:52.0593] snek: practical is a qualifier that can be used to exclude anything you don't like here [11:36:18.0104] I went to great trouble to make a splay tree that was indexable. It was clever. [11:36:21.0646] well i mean, we do have certain requirements in the spec like amortized O(1) access and such [11:36:27.0818] I mean, Maps and Sets are deterministically ordered based on some implementation (maybe in SM?) that had some sort of fancy encoded doubly linked list for ordering, IIRC [11:36:49.0116] sounds cool [11:36:57.0003] i should read more spidermonkey code [11:36:58.0218] fancy with XORs of pointers and such [11:37:05.0747] lmao that's a classic [11:37:06.0505] I don't know if it's still what they use [11:39:32.0302] LRU in the language would be awesome [11:39:44.0106] i see that used everywhere [11:40:21.0592] If we wait, IBM’s patent on ARC will expire and we will only need one. [11:40:47.0470] https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables [11:40:53.0666] is how set/map are ordered [11:40:58.0345] in implementations [11:41:01.0033] I believe [11:41:22.0476] it very small and nice, nothing excessively tricky [11:41:51.0255] thats not how v8's works afaict [11:41:54.0170] but that is neat [11:43:13.0167] got that link from syg but he might be out of date [11:43:32.0241] > <@devsnek:matrix.org> are there any practical ordered collection implementations that are not randomly accessible linked lists? [11:43:44.0678] "practical" may be doing some work to rule that out but it's the obvious one [11:43:53.0417] yeah that's what dan mentioned [11:44:24.0383] Oh is this WeakRef case my fault for not removing that use case from the WeakRefs readme? [11:44:28.0628] PRs welcome there [11:44:31.0169] sorry [11:44:32.0148] i just meant like, there are many ways to write things, but what are implementations actually using [11:44:45.0795] I assumed people would put a strongly held part at the beginning but it didn't show up in my example [11:44:52.0469] much like how we raised the requirements on sorting to be stable [11:46:16.0750] > <@littledan:matrix.org> I really like this proposal in its current form, overall. I want to note that Axel Rauschmayer is joining TC39 as an invited expert, and he may have input here as well. I read his feedback and was very confused by it; he wants this to work with iterables, and to be static functions, but working with iterables is just a fundamentally different thing than working with iterators [11:46:21.0365] it would be an entirely different proposal [11:46:26.0285] a different, worse proposal [11:48:24.0412] maybe we should put a link to https://stackoverflow.com/a/28513908 in the iterator helper readme [11:48:58.0861] might be nice to discuss dan minor's item since that's actually a potential stage 1 blocker [11:49:13.0116] this is stage 0, there is no "current proposal" [11:49:24.0592] > <@bakkot:matrix.org> it would be an entirely different proposal Well, yeah, I don't think he disagrees [11:49:43.0983] then I don't understand the feedback [11:49:48.0710] they don't particularly conflict [12:03:26.0768] jschoi: i would like to help champion this if eviction triggers are in scope, and if not, i'll champion its sister proposal [12:06:03.0350] Thank you. Let’s keep it in one proposal for now; welcome on board. (I think Hemanth H.M, the other co-champion, should be okay with it too!) [12:06:08.0951] > <@shuyuguo:matrix.org> jschoi: i would like to help champion this if eviction triggers are in scope, and if not, i'll champion its sister proposal * Thank you. Let’s keep it in one proposal for now; welcome on board. (I think Hemanth H.M, the other co-champion, should be okay with it too!) [12:13:07.0082] Are we only considering a very basic cache approach, or is the possibility of more complex caching strategies (i.e., cache key dependencies, user-defined change monitors, absolute or sliding expiration, etc.) on the table? [12:13:14.0036] > <@kriskowal:matrix.org> If we wait, IBM’s patent on ARC will expire and we will only need one. Yes, I really would like an ARCMap. If wishes were horses… Do Ecma or any of the big engines have a patent policy regarding patents that are about to expire in the US? (Also, I wonder if ARC’s patent is longer in other countries…) [12:30:17.0888] ARC patent was assigned to Intel so it's out of my hands ☹️ [12:31:25.0191] expires in Feb 2024 if there are no further adjustments [12:31:59.0261] could write a letter to Intel asking nicely for RF license [12:32:39.0621] Intel is an ECMA member [12:40:32.0426] > <@rbuckton:matrix.org> Are we only considering a very basic cache approach, or is the possibility of more complex caching strategies (i.e., cache key dependencies, user-defined change monitors, absolute or sliding expiration, etc.) on the table? Also, everything is on the table for discussion in https://github.com/tc39-transfer/proposal-policy-map-set/issues/2. [12:42:46.0726] Also, while writing https://github.com/tc39-transfer/proposal-policy-map-set/issues/7, I’m wondering if we shouldn’t try to revive that old Observables proposal, or at least keep the trigger API to be compatible with Observable… [12:48:04.0759] > Consistent with its participation in standard-setting organizations, Intel may voluntarily commit to license its patents that are “essential” for compliance with a standard on fair, reasonable and non-discriminatory (“FRAND” or “RAND”) terms. 🤔🤔🤔 [12:48:34.0741] * > Consistent with its participation in standard-setting organizations, Intel may voluntarily commit to license its patents that are “essential” for compliance with a standard on fair, reasonable and non-discriminatory (“FRAND” or “RAND”) terms. 🤔🤔🤔 [13:01:24.0897] > <@softwarechris:matrix.org> Intel is an ECMA member Yeah, we can feel free to go ahead with putting this in the spec, unless Intel withdraws in time, since we have our royalty free patent policy in TC39 [13:01:50.0859] littledan: Can you leave a comment on #2? [13:02:06.0501] what is ARCMap [13:02:19.0435] * littledan: Can you leave a comment on #2? [13:03:29.0500] Adaptive Replacement Cache [13:03:53.0543] It is an algorithm that slides between LRU and LFU depending on the observed effectiveness of each strategy on the working set over time. [13:04:11.0295] frecency? [13:05:19.0791] i guess this is technically not raw frecency [13:05:23.0392] interesting though [13:06:11.0404] > <@littledan:matrix.org> Yeah, we can feel free to go ahead with putting this in the spec, unless Intel withdraws in time, since we have our royalty free patent policy in TC39 > In case the implementation or use of the resulting standard incorporating said contributions requires patents or any other kind of intellectual property rights that I (or my represented organization) own, I (or my represented organization) grant a license free of charge to an unrestricted number of applicants on a worldwide, non-discriminatory basis, and under other reasonable terms and conditions to manufacture, use and/or sell implementations of the standard. https://www.ecma-international.org/tc39-royalty-free-technical-committee-members/ according to that page, Intel signed that agreement. IANAL but that's compelling [13:06:55.0795] indeed [13:08:22.0107] ibm and intel have both signed it [13:08:25.0851] very compelling [13:08:51.0230] right. as the patent has been assigned to Intel though, it's 100% theirs at this point [13:09:14.0681] there is a variant licensed under CDDL as well: https://github.com/openzfs/zfs/blob/master/module/zfs/arc.c [13:13:31.0669] it'd still likely be up to intel's legal team whether they contributed it in the first place tho [13:14:05.0857] well, I don't think we need to worry about that; I think the standards IPR opt-out process is our safeguard to reference [13:14:12.0757] * well, I don't think we need to worry about that; I think the standards IPR opt-out process is our safeguard to reference [13:14:21.0257] i would suspect the employees of that company may want to worry about it tho [13:14:53.0561] oh, yeah, that contribution seems complicated, not contradicting you there [13:14:56.0509] i wouldn't want someone to lose their job by trying to sneak a patented thing into the spec :-) [13:15:14.0872] I don't think we'd put that at risk; we'd be just using the standards IPR opt-out process [13:15:39.0716] IMO the main thing is, are we OK with proceeding with the things that happen after Stage 3 while risking that they may later opt out and not license the patent? [13:16:03.0791] right, i'm saying that i'm pretty sure all of my employers would have fired me for knowingly contributing a patented thing and requiring the legal team to intervene later [13:16:29.0936] the patent optout is an escape hatch, it's not carte blanche for delegates to volunteer their employer's patented IP [13:16:36.0526] would your employer's legal team need to intervene though? [13:16:51.0835] well, someone would need to find out and decide to opt out [13:16:55.0573] python has @memoize, no? [13:17:00.0730] so, yeah, check with your employer before contributing their IPR! [13:17:09.0919] so I don't know about Intel, but at IBM -- and I'm trying to be careful with my words here 🙂 -- being able to license or release stuff open source is predicated on whether or not it will compete with IBM products/services and affect the business in some way. (lost profit, etc.). I think for what we would want to be doing with ARC, it's difficult for me to see how it would compete with Intel's business interests, so strikes me as uncontroversial for the IP team to grant a license outright [13:17:14.0348] like I would assume we would want this to be a decorator [13:17:28.0239] rkirsling: that's not what it's called, but yes: https://docs.python.org/3/library/functools.html#functools.cache [13:17:32.0306] oops, thanks [13:17:35.0490] * oops, thanks [13:17:52.0425] this would be an awesome decorator if we supported decorators on functions lol [13:17:59.0645] i will never not be salty about this [13:18:08.0796] oh oops right [13:18:19.0086] Function decorators are held up because they don't really jive with function hoisting. IMO we should just say that decorated functions are not hoisted, but not everyone agrees. [13:18:26.0776] Python functions aren't hoisted, that's how they get through this [13:18:48.0446] function decorators are also held up because you can just call a function instead [13:18:52.0785] which doesn't work for class properties [13:18:57.0288] that is true in Python as well [13:18:59.0007] wait, so i could use a function declaration but cleanse it of hoisting with `@(x => x)` or something? that seems nice [13:19:00.0333] so there's a lot more motivation for class properties [13:19:11.0738] but yes that's true [13:19:56.0284] imagine if we had capture operator`@(& &1)` [13:23:03.0888] it's hard for me to picture why things would be limited to the first argument... you can have nested maps [13:23:35.0057] Also user-code maps with complex key relations. [13:23:50.0451] This does seem polyfillable, and it should be, but it still seems like a common need that makes sense to promote to the stdlib [13:36:07.0138] > <@littledan:matrix.org> that is true in Python as well only sort of; python doesn't have function expressions [13:38:55.0270] it seems like this proposal could go straight to stage 2, there is really only 1 way to design a solution to this problem, right? [13:39:45.0734] well, you could use syntax [13:39:52.0837] Kris Kowal: can you explain why you prefer syntax? that was kinda unclear [13:40:12.0061] yeah why would this not just be pulling lodash functions into the stdlib [13:40:45.0166] you can type this fine in TS [13:40:48.0159] Michael Ficarra: shu’s position is consistent with ours. [13:40:56.0499] as long as the keys are passed inline, anyway [13:41:15.0898] IF they're inlined [13:41:24.0877] computed property accesses are also fine if they're just string literals [13:41:30.0920] what would be harder is for JS engines to make ICs based on the keys being passed inline, the way they can for destructuring [13:41:31.0033] that doesn't mean you should favor computed property accesses [13:41:45.0126] yes, all the special reductions for pick/omit seems not desirable [13:41:46.0582] this sort of limitation is common in TS, OTOH [13:41:55.0204] like if it's not too onerous to extend syntax [13:41:56.0467] maybe that's fine [13:42:00.0847] but i wanna see something concrete [13:42:13.0826] for remote meetings, we need a little more time to object than that, I can't even unmute in that time (though I do not wish to object here) [13:44:26.0039] the syntax seems neat as well as optimizable and typeable, but... I dunno, it will take me more time to be convinced that we should add it. [13:44:44.0510] maybe we should [13:44:44.0758] strong 😬 toward the syntax personally [13:45:30.0226] I think I'd rather not have this than have syntax for it [13:45:58.0237] and I do want it [13:46:03.0747] stage 1 is a good place for this [13:46:47.0718] Michael Ficarra: how come? [13:47:23.0781] i am not pro-syntax to be clear, i'm pro exploration of syntax solutions until we make the call [13:47:30.0835] shu: I don't think it's worth incurring syntax cost, even though it is useful and common [13:47:43.0076] is that more than a feeling [13:47:51.0271] i was gonna say i don't think its common enough to warrant its own syntax [13:47:57.0595] okay, so it's about popularity [13:48:05.0336] * i was gonna say i don't think its common enough to warrant its own syntax [13:48:07.0611] it's about cost-benefit [13:48:33.0134] syntax has cost and we have to use it on things that have outsized benefits [13:48:45.0709] APIs are basically free [13:48:57.0537] i guess i also feel like we're not losing anything if this is a builtin function, like the api isn't worse [13:48:57.0767] Right, if this were extremely common and we really wanted to make it really terse and allow engines to have ICs here, the syntax might make sense [13:49:01.0498] my point is that it's not free [13:49:21.0219] APIs for property accesses that are expected to be very common end up not being free for performance [13:49:26.0475] so we should have that in the cost-benefit [13:49:32.0375] I'm not convinced it's so bad to have the string keys. Not as optimizable, but typeable in practice, and I'm not sure if it makes people's programming patterns more dynamic than they are today [13:49:38.0331] instead of just "syntax are expensive from a language design POV" [13:49:42.0415] that might be true [13:49:54.0157] shu: if we don't add it to the std lib though, people are gonna keep writing their own anyway [13:49:57.0055] arguably when we did Object.entries we already crossed the bridge of being OK with objects as key/value things (which they always were anyway) [13:50:03.0419] > <@littledan:matrix.org> I'm not convinced it's so bad to have the string keys. Not as optimizable, but typeable in practice, and I'm not sure if it makes people's programming patterns more dynamic than they are today i could be convinced of this [13:50:16.0234] I have definitely asked myself why I can’t just `phenomenalCosmicPowers.{itty, bitty, living, space}`. [13:50:28.0186] i think people use Object.entries in a dynamic way, while pick/omit seem to assume static knowledge of the shape of the object you're working with [13:50:29.0712] also while I think this will be common it will not be _that_ common [13:50:34.0846] i don't think the performance is so critical that we *must* take the most statically analyzable option [13:50:39.0609] * i don't think the performance is so critical that we *must* take the most statically analyzable option [13:50:56.0129] one of the motivations is that there are use cases with N properties, so you can't just type it all out statically - so you'll always be forced to pass strings [13:51:02.0338] we certainly could, but i am not yet convinced anyway [13:51:10.0789] > <@shuyuguo:matrix.org> i think people use Object.entries in a dynamic way, while pick/omit seem to assume static knowledge of the shape of the object you're working with * one of the motivations is that there are use cases with N properties, so you can't just type it all out statically - so you'll always be forced to pass strings [13:51:20.0701] yes, i could be convinced either way [13:51:23.0238] > <@bakkot:matrix.org> also while I think this will be common it will not be _that_ common Just be clear: is this common or not common!?!?!?! [13:51:31.0036] i am just pushing back against "APIs are free" [13:51:35.0097] either the whole program is Object.pick() or it's not called [13:51:44.0101] the thing that has cost here isn't just the weight of the language! [13:51:45.0035] if an API is so common that people are preferring it over syntax, can't we add syntax at that point? [13:52:00.0559] i don't see why we need to do that exploration via stdlib [13:52:04.0664] instead of just the userland libraries? [13:52:06.0302] historically we've preferred to add syntax *after* trying something out as API, like object spread/rest after Object.assign [13:52:22.0109] userland's demonstrated that we need these functions for a long long time [13:52:41.0104] the objection seemed to be about the potentially increased usage if it's standardized, right? [13:52:52.0993] so if that happens, then isn't that a stronger argument for syntax? [13:53:08.0211] I think that, given that the committee is moving a lot more stuff these days, we can just evaluate the syntax option and make a call, rather than potentially doing one and then the other (with potential not-fun mismatch!) [13:53:09.0604] tbh `abc.{a,b}` looks like it'd be an alternative syntax to `let {a,b} = abc;`, not creation of a new obj [13:53:32.0691] yeah it's a nice design of the syntax! [13:53:42.0053] oh oops that's the opposite of what you're saying? [13:54:04.0773] i also do not like the exact syntax that was proposed [13:54:32.0721] yeah I mean that `.{}` doesn't seem weird as a syntactic construct but it looks like it'd be creating bindings in the current scope [13:54:46.0676] `abc.{a,b}` is obvious to me, to wit, I’ve reached for that exactly in my work and been sad. [13:55:43.0594] `{ abc.{a,b} }` would be clearer to me, and have synergy with unix shell text expansions [13:57:16.0783] i still feel like the clearest thing to me is a nice api where you're saying something like `Object.pick(o, [k1, k2, k3])` [13:57:57.0430] i feel like that is superior to the syntax in terms of everything except potential engine optimization [13:58:01.0749] I will grant that other irresponsible generalizations of this syntax seem reasonable to me up to and including `ab.(a + b) === ab.a + ab.b` [13:58:24.0796] here's an unpresented proposal about syntax in the same space: https://github.com/rtm/js-pick-notation [13:58:51.0003] no endorsement! something to chew on though [14:03:02.0590] do people actually write dynamic sequence of callbacks? [14:03:14.0188] that seems pretty hard to reason about [14:04:00.0119] that said i also love first-class goto labels [14:06:15.0615] +1 to ljharb 's point [14:10:30.0124] > <@shuyuguo:matrix.org> do people actually write dynamic sequence of callbacks? RxJS rings a bell (along with the myriad libraries that depend on it) [14:24:47.0940] I really would like an operator, but I would also like to not continually alienate large sections of the ecosystem that really would like unary function pipelining [14:25:49.0525] well, JS really tried to thread this needle with his middle proposal with both a topic and unary pipelining, but everyone thought that was too complex [14:28:20.0342] what if instead, only API and not syntax [14:28:20.0552] I don't think this can be considered a different problem space; it's only a different solution space [14:28:32.0516] I think actually having one version implemented will get people to calm down about their version [14:28:41.0290] as long as it's still theoretical, you can argue [14:29:28.0928] > <@littledan:matrix.org> well, JS really tried to thread this needle with his middle proposal with both a topic and unary pipelining, but everyone thought that was too complex Smart mix… 🥲 [14:29:37.0749] If we have API and no syntax, why not not have F# pipes? Hack-style's benefit is in working with `yield`, `await`, and arbitrary expression evaluation. If we were to throw those concerns out in favor of an API, how is that any different from having chosen F#-style? [14:29:55.0848] because syntax is much more expensive than APIs, as previously mentioned [14:33:01.0195] Except `|>` without a topic or PFA has no conflict with any existing syntax (i.e., no NLT, no changes to InputElementX goals, etc.), and is much more readable than `Function.pipe(x, F(...), ...)`. [14:33:23.0870] i do kind of wonder what the rates are would be to get people to fix up the bot [14:33:43.0251] like can I just hire two or three friends who are between jobs at $30/hr to do the bot shepherding [14:35:10.0243] it was appropriate to call out insensitivity [14:35:17.0297] that wasn't a CoC issue [14:35:53.0704] we have 11 topics on TCQ and no time left on this topic... [14:36:10.0869] > <@rbuckton:matrix.org> Except `|>` without a topic or PFA has no conflict with any existing syntax (i.e., no NLT, no changes to InputElementX goals, etc.), and is much more readable than `Function.pipe(x, F(...), ...)`. I still remain concerned that the meaning of `x |> veryLongThing(veryLongThing, ^^, veryLongThing)` completely changes semantics (from an n-ary function call to a unary tacit call on a metafunction call) when omitting the `^^`. This is a big burden on readers. [14:36:37.0569] This is also why I pushed in those early errors requiring and guaranteeing that the topic is in every pipe body. [14:36:48.0450] * This is also why I pushed in those early errors requiring and guaranteeing that the topic is in every pipe body. [14:36:54.0188] I did not support "smart-mix" for that very reason. [14:37:22.0979] I also did not support smart mix, smart, but not smart enough :P [14:37:35.0274] > <@rbuckton:matrix.org> I did not support "smart-mix" for that very reason. Yes, I sympathize. Though at the very least smart mix limited unary-tacit-calls-on-metafunction-calls to relatively simple and quickly readable property chains. [14:37:48.0451] Hack-style requires a topic. F#-style requires unary function application. PFA would have helped with producing unary functions for use with F#. [14:38:48.0503] I support F# + PFA :P [14:40:44.0058] I also feel it's not right to call hack-style to hack-style, because Hack actually not support await... I also feel it's not right to call it topic-style because it's not like topic usage in real topic style languages like perl... In real topic style languages, topic mostly are implicit, only rare cases u need explicitly use topic ref. [14:41:27.0910] I think “topic style” is appropriate. The word “topic” (as Perl uses it) comes from linguistics: https://en.wikipedia.org/wiki/Topic_and_comment [14:41:33.0503] The topic is explicit in many human languages. [14:42:39.0079] * I think “topic style” is appropriate. The word “topic” (as Perl uses it) comes from linguistics: https://en.wikipedia.org/wiki/Topic_and_comment [14:43:12.0319] I don't agree. Topic means it's the context so people know the context of it and do not need to repeat explictly call it, this is what I understand of topic style. [14:43:13.0284] See also: https://www.perl.com/pub/2002/10/30/topic.html/ [14:44:05.0014] > <@haxjs:matrix.org> I don't agree. Topic means it's the context so people know the context of it and do not need to repeat explictly call it, this is what I understand of topic style. Like in Japanese, topics are explicit and marked with wa は: https://en.wikipedia.org/wiki/Topic_marker [14:44:07.0251] In perl, many operations just use $_ but only in rare case u need explicitly use $_ [14:44:14.0988] And in Korean, topics are marked with 은/는. [14:44:25.0298] Anyways, Perl took it from that original linguistics usage. [14:44:40.0197] * And in Korean, topics are marked with 은/는. [14:44:42.0023] and in Chinese it just sits in front [14:44:52.0556] I suspect IS is about to suggest recordings and we are not going to get consensus for recordings [14:45:01.0434] > <@rkirsling:matrix.org> and in Chinese it just sits in front Huh, apparently Classical Chinese did have a topic marker: 者. Today I learned. [14:45:35.0958] I am even more leery of recordings these days than I was two years ago given stuff like https://github.com/neonbjb/tortoise-tts [14:45:38.0770] this is why I suggested we do this on the Reflector instead of in plenary... [14:46:05.0567] I KNEW this topic would drag on forever [14:47:16.0615] i don't think it even makes sense as like, a discussion topic [14:48:14.0897] chairs, I don't think we should extend this topic [14:48:20.0926] the conversation happening in the queue rn [14:48:21.0779] > <@rkirsling:matrix.org> and in Chinese it just sits in front * Huh, apparently Classical Chinese did have a topic marker: 者 (zhě). Today I learned. [14:48:43.0531] we had another topic from Richard following this and I don't think there's any reason to have this in plenary over the Reflector [14:49:19.0203] yeah agree [14:49:45.0792] we put conclusions in the notes; they are easy to find [14:49:56.0516] > <@jschoi:matrix.org> Huh, apparently Classical Chinese did have a topic marker: 者 (zhě). Today I learned. Yeah in classical chinese 者 will only be used if we want to make emphasis. In most cases, it is omitted. [14:49:59.0268] I have never had difficulty finding those [14:50:17.0764] I don't think there would be that much benefit in putting those in their own docs [14:50:42.0132] I think it's helpful to discuss the topic, so long as people keep feedback succinct and keep it moving. [14:52:16.0245] what annoys me is that I am certain google _could_ dramatically improve the STT if they really wanted to with like 5% of the budget they spent on PaLM [14:52:45.0278] but I can't make them do it and no one else seems to have a better realtime model, or at least this was true in 2020 [14:53:07.0914] scrubbing through audio would suck lol [14:53:23.0826] So IMO, topic reference is more like implicit parameter in other languages (eg. `it` in Kotlin), not like $_ in perl [14:53:59.0556] But in those languages, implicit param is the feature of function/block, not bind to some operator like pipeline. [14:54:05.0048] we would still have to pay someone to transcribe the audio/video [14:54:08.0449] yeah recordings alone are almost useless unless you also run STT on them [14:54:15.0292] i'm not against recordings but they are not useful in place of notes [14:54:26.0960] they serve a different function [14:54:48.0739] they will be ~99.6% useless [14:54:59.0670] > <@haxjs:matrix.org> So IMO, topic reference is more like implicit parameter in other languages (eg. `it` in Kotlin), not like $_ in perl In addition to the original use from linguistics (which can be explicit or implicit), “topic variables” also have been used on explicit-only variables: https://rosettacode.org/wiki/Topic_variable But I don’t want to derail the thread; this is all about steganography right now. [14:55:18.0137] stenography [14:55:35.0704] Oops. [14:56:02.0784] ... what if the bot goes on strike, will IS get ecma to pay for stenography at that point [14:56:03.0753] I like my topic better. Let’s talk about TC39 steganography… [14:56:06.0349] the bot could go on strike [14:56:23.0438] > <@jschoi:matrix.org> I like my topic better. Let’s talk about TC39 steganography… why not both [14:56:35.0400] i feel like the only relevant topics of discussion are [14:56:54.0121] 1) who wants to pony up cash 2) are volunteers willing to continue [14:57:08.0586] > <@bakkot:matrix.org> the bot could go on strike I mean yeah, I was going to suggest just refusing to do notes for a whole meeting [14:57:11.0076] seize the means of production [14:57:18.0080] that'd hurt _everyone_ but... [14:57:20.0837] > <@shuyuguo:matrix.org> 1) who wants to pony up cash > 2) are volunteers willing to continue This convo is definitely affecting 2. [14:57:45.0835] * that'd hurt _everyone_ but... [14:57:53.0660] I can say I won’t take notes because I’m not smart enough to listen and write at the same time. Also: RSI risk. [14:58:36.0592] The times I’ve volunteered left me a dried out husk. [14:58:40.0241] if stenography gets torpedoed because of the opinions of people who do not volunteer regularly, then I am unlikely to be willing to continue volunteering to take notes [14:58:53.0791] > <@pchimento:igalia.com> if stenography gets torpedoed because of the opinions of people who do not volunteer regularly, then I am unlikely to be willing to continue volunteering to take notes same [14:59:36.0297] someone who notetakes regularly needs to say that on the queue please. [14:59:43.0288] * someone who notetakes regularly needs to say that on the queue please. [15:00:02.0958] we're unlikely to get to the end of the queue at this point [15:00:19.0813] "point of order: notetakers are considering strike" lol [15:00:20.0431] "discuss current topic" is often relevant :-p but fair [15:01:46.0127] > <@jschoi:matrix.org> In addition to the original use from linguistics (which can be explicit or implicit), “topic variables” also have been used on explicit-only variables: https://rosettacode.org/wiki/Topic_variable > > But I don’t want to derail the thread; this is all about steganography right now. Thank u for the link, and the definition it use: "A topic variable is a special variable with a very short name **which can also often be omitted.**" 😉 [15:04:14.0063] if we paid all the delegates who are taking notes at our going rates, we would cost... like an order of magnitude more than the professional stenographers [15:05:23.0229] new rule: don't shoot down the steno if you have no alternate solutions with a concrete plan to manifest them [15:05:30.0439] 🤷 [15:05:48.0471] it is a crass thing, but it would be a good visceral reminder to tally up the per-hour cost (probably per minute given the attendance and our employers, actually...) of tc39 [15:07:18.0737] ptomato ty for your queue item ❤️ [15:07:21.0455] I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting [15:07:40.0832] > <@sarahghp:matrix.org> I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting rip istvan [15:08:01.0830] we would lose spec download stats [15:09:17.0909] > <@sarahghp:matrix.org> I would like to suggest that we track how long any given person speaks in a meeting and then make the notetaker list in that order for the next meeting lots of people aren't really physically/mentally able to take notes in realtime, tbf [15:09:45.0951] people mentioned RSI but the visual burden is also intense [15:10:23.0218] then we should pay pros [15:10:28.0931] yes we should [15:10:35.0431] indeed [15:11:59.0087] it would be nice to end early [15:12:39.0603] I thought today only went to 15:00 Pacific? [15:12:46.0236] nope, 16:00 [15:12:52.0541] * nope, 16:00 [15:13:08.0054] draft schedule lies... [15:13:29.0828] yes all the way to 4 poor thing 😜 [15:13:30.0834] or the agenda does, i guess [15:13:47.0091] * yes all the way to 4 poor thing 😜 [15:14:15.0175] > <@sarahghp:matrix.org> yes all the way to 4 poor thing 😜 I'm not Pacific either [15:14:42.0236] I edited all three days’ notes of a plenary last year, and it took two entire weekend days, and I do not plan to do it again. [15:14:43.0613] (are we going to get to incubator chartering) [15:14:53.0231] > <@michaelficarra:matrix.org> I'm not Pacific either I'm sorry I just meant my teasing to hit jordan, not other casualties! [15:18:03.0830] JSConf.eu paid live stenographers and it was amazing [15:18:09.0204] Everyone loved it [15:18:20.0821] yeah that was awesome [15:19:10.0379] Roguelike, a very tiny niche boutique conference, also paid a stenographer. [15:20:04.0141] another point, which I am not going to make on the queue, is that IMO the errors that the transcriptionist makes are much easier to correct after the fact than the errors the bot makes [15:20:17.0880] like sometime the transcriptionist misses a word or gets something wrong, but it's rarely outright gibberish [15:20:44.0713] I think Shane did cover that [15:20:45.0173] the worst stenographer errors were when they got behind and skipped a sentence or two, which is pretty hard to correct even moments later [15:21:03.0643] the bot does that sometimes and I fix it up ok when I'm doing notetaking [15:21:14.0049] (usually when the wifi drops or something) [15:21:28.0477] admittedly not as often, though [15:22:56.0273] I'm really hoping the stenographer will be significantly better with non-native speakers than the bot was; the bot was awful [15:25:32.0846] Rob Palmer ☝️ [15:25:35.0059] > <@kriskowal:matrix.org> Roguelike, a very tiny niche boutique conference, also paid a stenographer. (You’re going to get me back into roguelikes again……For me, “true” Berlin Interpretation roguelikes might be the purest form of game in the world.) [15:26:36.0213] `#tc39-nethack` [15:27:10.0786] …Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda, and would they have been broadcast remotely? [15:27:20.0433] * …Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have happened on the agenda. [15:27:26.0837] * …Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda? [15:27:34.0777] * …Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda, and would they have been broadcast remotely? [15:27:51.0986] > <@jschoi:matrix.org> …Also, did any breakout sessions happen in this plenary? I cannot tell because I am remote. Actually, I don’t know how the breakout sessions even would work; would they have been put on the TCQ agenda, and would they have been broadcast remotely? having been to in-person plenary before covid: there's no such thing as a breakout session, only informal hallway conversations during break times [15:28:31.0748] Waitamoment…We haven’t done incubator rechartering, right? shu [15:29:21.0079] there was a breakout thing once but it was because there was an entire day of empty agenda [15:33:02.0327] mpcsh: we have definitely done true breakout sessions before [15:33:45.0846] one of the Apple campus meetings and the one in that weird NYC cult building are at least 2 I can recall [15:34:46.0056] > <@michaelficarra:matrix.org> one of the Apple campus meetings and the one in that weird NYC cult building are at least 2 I can recall ………NXIVM’s building? [15:34:54.0340] nah, different cult [15:36:39.0383] it was the masons, or something [15:36:43.0835] yeah [15:36:51.0978] they had like, a gilded statue of george washington on one of the floors [15:37:19.0798] lots of pictures of old white dudes in costumes hung on the walls [15:37:19.0799] is that not normal for all buildings? [15:37:22.0901] * is that not normal for all buildings? [15:37:39.0114] oh this is delegates [15:41:57.0024] oh yeah the masonic hall [15:42:01.0879] and like kanye was there or something? [15:42:04.0693] weird time [15:42:16.0279] yeah dherman saw kanye [15:43:30.0042] kanye in a maga hat in the basement of the masonic lodge [15:43:37.0100] * kanye in a maga hat in the basement of the masonic lodge [15:44:01.0886] for stage 2 [15:46:35.0031] syg: can you put the chartered calls in the notes [15:46:55.0624] will do now [15:58:22.0092] is document.all the only web non-function object with a [[Call]]? [16:04:13.0166] > <@rick.button:matrix.org> is document.all the only web non-function object with a [[Call]]? seems like it https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#htmlallcollection [16:09:19.0292] well there could be more [16:10:24.0033] no [16:10:29.0033] just document.all [16:11:18.0536] separate from that, I'm confused why `Function.prototype.bind.call(document.all).__proto__ === Object.prototype` and not `document.all.__proto__` [16:13:08.0065] * separate from that, I'm confused why `Function.prototype.bind.call(document.all).__proto__ === Object.prototype` and not `document.all.__proto__` [16:13:49.0937] * separate from that, I'm confused why `Function.prototype.bind.call(document.all).__proto__ === Object.prototype` and not `document.all.__proto__` [16:13:53.0017] oh wait, it is [16:16:04.0797] wait document.all is also callable? [16:16:53.0320] yes [16:18:22.0315] That’s why Leo brought that topic about if ShadowRealm should special case it [16:18:48.0022] As it’s callable it can go through the boundary [16:19:03.0740] And becomes a wrapped function on the other side [16:19:10.0771] is there a reason we don't just call it a function with a bunch of properties on it [16:19:19.0751] like yeah its missing the prototype but you can do that to a function anyway [16:19:21.0633] is it the case then that all objects with [[Call]] on web are either one of the function-family (normal/async/generator) or its a HtmlAllCollection? with no exceptions [16:21:48.0098] i grepped, it is the only reference to `[[Call]]` in the whole spec so I guess so yeah. [16:21:53.0487] * it is the only reference to `[[Call]]` in the whole spec so I guess so yeah. [16:22:02.0629] * i grepped, it is the only reference to `[[Call]]` in the whole spec so I guess so yeah. [16:30:18.0967] Michael Ficarra: I can't post in TC39 Editors for some reason, but see my response at https://github.com/tc39/ecma262/issues/2808#issuecomment-1192021230 [16:39:27.0520] > <@devsnek:matrix.org> like yeah its missing the prototype but you can do that to a function anyway it technically is a "function object" because it has [[Call]] but it isn't a built-in function exotic object 2022-07-22 [17:30:06.0708] Oh god, I finally have a real use for `Symbol.species`: to simulate async contexts. [12:42:25.0396] Nope, don't need `species` at all, just need to patch `Promise.prototype.then` and you get all the benefits. [12:48:31.0601] Justin Ridgewell: even given that `await` on a native promise will bypass `Promise.prototype.then`? [12:49:19.0106] It's not possible to properly hijack `await` with `species` either [12:49:33.0099] You have to manually restore after the `await` is over. [12:49:33.0237] true, true [12:49:34.0182] well [12:50:13.0480] you _could_ replace `Promise.prototype.constructor` with something other than `Promise`, and then `await` would always fall back to the slow path where it calls the actual `.then` [12:50:16.0075] please do not do this though [12:50:30.0638] especially given that you're thinking of changing how the fast-path in `await` works [12:50:50.0526] * you _could_ replace `Promise.prototype.constructor` with something other than `Promise`, and then `await` would always fall back to the slow path where it calls the actual `.then` [12:51:04.0973] I believe the await will still resume 1 tick after settling the patched promise? [12:51:47.0832] depends on what your implementation of `.then` does [12:51:55.0192] it _could_ just call the continuation synchronously, if you wanted [12:51:57.0761] though, again, don't [12:52:26.0886] oh, wait, no, that's a lie [12:52:35.0978] it will always take at least 1 tick, yes [12:52:42.0154] Yah, you consume the userland promise into a native, then chain on the native, which must wait 1 tick. [12:52:58.0211] * Yah, you consume the userland promise into a native, then chain on the native, which must wait 1 tick. [13:16:56.0213] bring back the async context proposal [13:44:23.0172] Might need to [13:44:41.0912] We could do it in a way that's not so magic. [16:44:20.0851] oh hey, github fixed their previews for large documents like spec.html! [16:44:47.0852] you can actually expand context in the pr preview now, instead of those buttons silently failing 2022-07-23 [17:04:12.0014] oooo nice [17:37:26.0601] > <@devsnek:matrix.org> bring back the async context proposal What is the async context proposal? I want to know! Because I had been working a while back on a “generic context” proposal that would include “async contexts”… [18:39:16.0761] > <@jschoi:matrix.org> What is the async context proposal? I want to know! Because I had been working a while back on a “generic context” proposal that would include “async contexts”… https://github.com/legendecas/proposal-async-context this? [19:42:17.0967] > <@jschoi:matrix.org> What is the async context proposal? I want to know! Because I had been working a while back on a “generic context” proposal that would include “async contexts”… I'd be interested to know more about the "generic context" proposal 😁 [19:43:47.0502] Hah hah 🤓 2022-07-26 [10:10:45.0745] Record&Tuple monthly call starting in 50mins for anyone interested in joining. Details in TC39 calendar [10:12:12.0695] ah darn, that's a convenient time but I happen to have a conflict today [10:13:49.0557] You’ll be missed! 2022-07-30 [21:10:08.0232] hello [21:10:14.0784] I want to maintain this repo https://github.com/tc39/dataset [21:10:26.0176] but I don't have write permission to it [01:19:15.0324] fixed.