2021-08-01 2021-08-02 2021-08-03 [06:23:16.0421] Agenda for today's wasm CG call also include string encoding discussion https://github.com/WebAssembly/meetings/blob/main/main/2021/CG-08-03.md 2021-08-04 [01:09:00.0524] Please could I get a review for https://github.com/tc39/notes/pull/144 2021-08-05 2021-08-06 [15:15:09.0146] I’d like to champion my first (small) proposal (as a delegate from Indiana University) and get it added to the August meeting’s agenda. I’ve never done this before—do I just open a pull request to tc39/agendas? 
(The proposal is at https://github.com/js-choi/proposal-array-async-from, with specification at https://jschoi.org/21/es-array-async-from/. No slides yet.) [15:15:31.0250] * I’d like to champion my first (small) proposal (as a delegate from Indiana University) and get it added to the August meeting’s agenda. I’ve never done this on my own before—do I just open a pull request to tc39/agendas? 
(The proposal is at https://github.com/js-choi/proposal-array-async-from, with specification at https://jschoi.org/21/es-array-async-from/. No slides yet.) [16:22:23.0754] jschoi: yup, that's all! you do need to open the PR >= 10 days before the meeting, so people get a chance to review, but you've got another couple of weeks before that deadline [16:22:35.0554] (though earlier is better, of course) [16:22:42.0522] bakkot: Thank you! [16:30:49.0968] jschoi: commentary on the proposal: I like it, but you should be aware that the iterator helpers proposal includes a `toArray` method on async iterators which accomplishes the same thing, so you might get pushback on it being duplicated with that [16:30:56.0119] personally I think it's fine though [16:53:24.0287] Heh, if they’re already fine with duplicating `Array.from`, then surely they could stand a little more duplication with an `Array.asyncFrom`. [16:54:07.0580] * Heh, if they’re already fine with duplicating `Array.from`, then surely they could stand a little more duplication with an `Array.asyncFrom`. Anyways, thanks, and we’ll see. 2021-08-07 2021-08-08 [18:25:11.0317] hi bakkot I have to say I really like the alternative design of do expression (https://github.com/theScottyJam/proposal-statements-as-expressions/issues/3) [18:25:35.0970] IMO that's the real meaningful way to turn statements into expressions [18:25:55.0640] without the complex early errors that do expressions currently have [18:26:38.0504] and my idea in the link above also allows the "temp variable" case. [18:27:33.0393] To be short: We add `if expression` and `try expression`. (`throw expression` has it's own proposal, `switch` has `pattern matching` as the expression version) [18:28:51.0600] Then we add a `ExprBlock`, that in form of `{` `OneOrMore Declaration or Expression` `Expression``}`) [18:29:07.0216] * Then we add a `ExprBlock`, that in the form of `{` `OneOrMore Declaration or Expression` `Expression` `}` [18:29:19.0656] * Then we add a `ExprBlock`, that in the form of expr `{` `OneOrMore Declaration or Expression` `Expression` `}` [18:29:50.0098] So we can do ```js const sth = expr { const tmp = random() tmp * tmp } ``` [18:30:42.0593] meanwhile `for` loop, `break`, `continue`, `return`, `if-without-else` are naturally syntax error in the form above. [18:31:39.0290] That brings more composable syntax sets for developer to use (`if expression`, `try expression`, `pattern matching`, `throw expression`, `expression block`, ...) [18:32:07.0390] cc HE Shi-Jun I guess you will like this idea too [18:35:37.0500] (and I still don't think using break continue and return in the expression position is a good idea) [23:31:54.0179] Jack Works: thanks for the suggestion, I'll take a look in a bit [23:44:31.0139] > <@bakkot:matrix.org> Jack Works: thanks for the suggestion, I'll take a look in a bit I have posted into the GitHub issue 2021-08-09 [01:55:24.0434] The code of conduct continues to mention former members as if they are current. Is someone planning on updating this list? https://tc39.es/code-of-conduct/#code-of-conduct-committee 2021-08-10 2021-08-11 2021-08-12 2021-08-13 [10:01:58.0003] anyone interested in the arraybuffer-base64 proposal, please sign up for the incubator call: https://github.com/tc39/incubator-agendas/issues/19 [10:31:11.0188] that's the charter, the call issue is here: https://github.com/tc39/Reflector/issues/393 2021-08-14 2021-08-15 2021-08-16 2021-08-17 2021-08-18 2021-08-19 2021-08-20 2021-08-21 2021-08-22 2021-08-23 [16:21:05.0478] Could we get https://matrix.to/#/!mjlgwjKxWUpgSgeCQU:matrix.org?via=matrix.org&via=igalia.com added to the TC39 space? [16:22:28.0133] Rob Palmer maybe? [16:24:22.0651] Done 2021-08-24 [02:27:52.0256] Hm, makes me think if we should add the Temporal champions room to the space as well... [02:28:30.0788] for discoverability if nothing else 2021-08-25 [12:18:23.0840] hey, a thought -- we are quite packed for this meeting [12:18:44.0855] how about we do blitz updates? for those who are willing to significantly shorten their presentations [12:19:03.0253] so, for example i can shorten my presentation to 3 minutes maybe? [12:24:45.0394] This is a good idea! Please update the agenda if you are willing to shorten your session. As inspiration, I recommend reading the minutes for Chip's updates on ECMA-404. They are admirably short. Be like Chip. [12:26:24.0680] maybe we can do it lightning talk style, people update their thing with "blitz" or somethinig, and we set aside 15-20 minutes for all of them? [12:39:23.0277] Maybe also, at the beginning of the meeting and topics, we can give people an extra chance to shorten their timebox? [12:51:23.0113] +1 can't rely on enough delegates reading this channel outside of plenary [13:08:03.0325] I would be happy to shorten the Temporal item if delegates feel like they had enough of a chance to review the slides and the normative PRs being presented beforehand, and they prove uncontroversial (as I hope they will). I don't know if I can count on that happening, though. 2021-08-26 2021-08-27 2021-08-28 2021-08-29 2021-08-30 [08:41:28.0252] This special meeting (non-plenary) begins in 20 mins (09:00PDT). https://github.com/tc39/Reflector/issues/394 [08:50:14.0243] Reminder: There is a spreadsheet linked from that issue ^^^ that lets you enter questions ahead of time. I encourage folk to use it to assist record keeping. [11:42:29.0413] Do the chairs plan to publish a schedule of timeboxes for this week's TC39 meeting on HackMD as has been done in the past? [11:48:00.0154] Yes. We slightly delayed publishing to allow for timebox reductions. There is way too much on the agenda. 2021-08-31 [18:19:50.0430] https://github.com/tc39/Reflector/issues/388 says, “Sign-in form will be added before the meeting - fill in the sign-in form and you'll get the link”. Sorry for bothering, but where’s the sign-in form? [18:25:30.0854] presumably it'll be added in the next 12.5 hours [20:42:51.0236] sorry i didn't get the schedule up earlier y'all [22:31:34.0523] oh my look at that overflow https://hackmd.io/@tc39-chairs/rJJlSXjbF [06:51:09.0728] The meeting starts in 9 mins [06:51:25.0223] if anyone is having trouble joining, please say [06:57:47.0368] nothing to report for ECMA-402 btw [06:57:57.0866] and I'll try to speedrun my DurationFormat presentation [06:59:25.0925] Rob Palmer: don't see the sign-in form on reflector? [06:59:44.0278] or... i'm looking at wrong meeting... [06:59:52.0959] https://github.com/tc39/Reflector/issues/388 [06:59:55.0183] Issue 388, under "Video Conference" [07:00:18.0488] (we can put reflector links here, but not the signin form or the notes) [07:00:47.0782] Room subject updated! [07:10:22.0647] experiencing technical difficulties, will rejoin jitsi shortly [07:13:32.0688] oh im sorry [07:17:35.0160] jitsi does not seem to like my webcam. [07:18:11.0823] rbuckton: i saw you for a sec! [07:19:21.0739] thanks for taking that one, ljharb [07:19:49.0045] I had to step away and the moment I got back and sat down, my topic was up lol [07:19:51.0701] I just got flustered [07:23:01.0096] slides, for anyone with technical difficulties: https://docs.google.com/presentation/d/177vM52Cd6Dij-ta6vmw4Wi1sCKrzbCKjavSBpbdz9fM/edit [07:26:09.0569] I think optional catch went straight to stage 3 in one meeting and then stage 4 the next meeting? [07:26:12.0456] it was fast [07:26:43.0838] behind optional catch, fastest includes Object.hasOwn, Object.fromEntries, Object.entries/values, iirc [07:27:09.0981] i see [07:27:19.0157] I think there were some really fast String.prototype ones, too [07:27:24.0361] note for tcq. Item 8, change-array-by-copy. I'll be presenting, instead of Robin. [07:27:27.0114] i should be proposing stuff to be under Object for a faster speed then [07:27:57.0889] it'd be great if we can call for explicit support for consensus [07:28:01.0042] shu: Object.at when? [07:28:08.0336] Ashley Claymore: IIUC, the presenter listed in TCQ doesn't matter all that much [07:28:10.0160] maybe getting a couple people to support things for each stage advancement [07:29:20.0346] Where’s the question queue? Is it just the 8x8 Meet chat, or is it something special? [07:29:40.0279] jschoi: TCQ [07:29:45.0789] there's a link in reflector [07:29:59.0361] Thank you! [07:32:17.0857] Any reason why I shouldn't tweet about `static {}` achieving stage 4 consensus? [07:34:58.0126] we didn't add flatMap to TypedArray? 🤔 [07:36:25.0899] is there a usecase? [07:36:41.0732] rbuckton: go for it, commit's pushed to the proposals repo already [07:41:13.0488] hello everyone [07:44:39.0930] we should add `setAt` to arrays [07:44:42.0960] solves this problem [07:45:48.0863] I mean we probably should add set() to arrays, if TypedArray has it [07:46:06.0650] kinda weird otherwise [07:46:18.0454] not stoked about adding more mutators to Array.prototype tho [07:46:35.0663] it's cool it's just an alias [07:46:49.0353] (with negative-wrapping magic, granted) [07:47:45.0275] there's a simple two step solution here: 1) at() returns a reference instead of a value 2) change assignment semantics to allow new values to be returned [07:48:21.0362] ah yes simple [07:48:51.0610] hell yeah brother, we never unshipped function calls as LHS of assignments syntactically [07:49:22.0023] TA.p.set throws for negative indices [07:49:29.0419] which, I guess we could probably change that to wrap like `.at` [07:51:12.0743] though actually TA.p.set has this behavior where it spreads arrays which are passed, which we would probably not want to do with A.p.set [07:51:20.0109] so maybe not actually feasible to copy it over [07:51:44.0942] > <@ljharb:matrix.org> rbuckton: go for it, commit's pushed to the proposals repo already I shouldn't have waited, Rick Waldron beat me to it :) He has a larger audience though, so I'm happy either way. [07:52:02.0674] lol you can still tweet about your own proposal even if others have [07:52:05.0227] but up to you ofc [07:52:34.0201] Already did. [07:53:00.0677] it seems like the list of methods should be decided before stage 2? [07:54:18.0705] > <@devsnek:matrix.org> there's a simple two step solution here: > 1) at() returns a reference instead of a value > 2) change assignment semantics to allow new values to be returned I would like to introduce you to my friend https://github.com/rbuckton/proposal-refs (may propose soon depending on outcome of Fixed shape objects proposal) [08:00:02.0102] I don't get why everything on Tuple needs to be on Array [08:00:30.0619] a tuple is conceptually an immutable array [08:01:34.0018] bakkot: One hope is that it'll be easy to write code that's generic between Tuples and Arrays [08:01:46.0311] who is objecting to consensus? [08:02:35.0132] littledan: so, that seems like a good motivation for all the _access_ methods to work. it seems like a strange goal to say you want _mutating_ code which is generic between Tuples and Arrays, though [08:02:48.0356] Ashley Claymore: please work on a rough initial reduced list and link it here for interested parties before end of the plenary if possible [08:02:52.0272] I am a bit uncomfortable with how this advancement went [08:03:03.0929] why? [08:03:08.0008] > <@michaelficarra:matrix.org> I am a bit uncomfortable with how this advancement went Did you want to block it? [08:03:09.0547] I was about to point out that @aki's mic was making noise, but I think she said her mic went out and it seems to be better now. [08:03:12.0138] I mean, the wording was a bit weird [08:03:22.0727] i mean the timebox rushing is uncomfortable but i don't think there was actual objection [08:03:28.0677] if someone was on the queue and wanted to block, that should of course be respected [08:03:33.0147] I didn't see what the timebox items were [08:03:38.0765] * I didn't see what the queue items were [08:03:43.0206] since mozilla worked it out and kevin and i wanna see a list [08:03:56.0541] and that list... can just be communicated here, since nobody else asked for it [08:04:25.0757] I just feel like there wasn't agreement between the chairs and the rest of the committee about whether we covered everything sufficiently for advancement [08:04:50.0789] it would've taken the same amount of time to ask, "is there consensus?" and give 15 seconds of uncomfortable silence for anyone to interject, as to have that argument [08:05:00.0380] maybe we can add that as a blitz bonus topic [08:05:28.0073] anyway chairing is hard; Aki is doing well [08:07:06.0228] The queue items weren't blockers, but in the future if we run up against timebox and someone raises a question we will move on even if there are no obvious objections. [08:07:30.0925] I am fine with moving on without advancement whenever we're even a second over timebox, but rushing advancement, whether within or without timebox, doesn't seem right [08:08:16.0064] Michael Ficarra: i don't disagree. i think I should have held firm. [08:10:21.0725] > <@shuyuguo:matrix.org> Ashley Claymore: please work on a rough initial reduced list and link it here for interested parties before end of the plenary if possible Will do. In the mean time there is discussion here if useful https://github.com/tc39/proposal-change-array-by-copy/issues/27 [08:16:43.0603] ryzokuken: I'm still happy to review [08:18:06.0800] I ❤️ this proposal [08:19:16.0050] thanks Michael Ficarra 😇 [08:20:01.0987] TabAtkins: & jschoi y'all want to hop on that next 30 min slot? [08:20:10.0167] i'm ready for it [08:21:02.0640] Ready; hoping my microphone will work. [08:28:47.0291] honestly it actually does seem a little bit analogous to shadow DOM [08:30:34.0630] "analogous to" isn't always great if it doesn't actually hook into the same concept tho. "this is theoretically similar to shadow DOM, but doesn't actually have anything to do with shadow DOM" can be problematic for learning. [08:30:37.0243] if it is analogous then that's a stronger argument _for_ this name [08:30:51.0413] * if it is analogous then that's a stronger argument _for_ this name [08:31:35.0946] I'm not objecting, but I suspect the HTML/DOM editors might have an opinion on it [08:31:49.0737] i confirmed with domenic he's fine with SHadowRealm [08:31:51.0942] Domenic has been involved in the thread at least [08:31:53.0815] could ask anne i guess [08:31:55.0692] i don't get the analogy to shadow dom personally [08:34:19.0420] shadow dom and shadow realm both have the property of, it's a separate X where changes in it do not affect the main X except through specific boundaries [08:36:25.0049] devsnek the analogy is weak. Other than what Bakkot has said, it just indicates ShadowRealm is not the main Realm. [08:36:37.0631] can someone please give cjtenny access to post? [08:37:10.0736] > <@leobalter:matrix.org> devsnek the analogy is weak. Other than what Bakkot has said, it just indicates ShadowRealm is not the main Realm. This is exactly what I think about the name and exactly what I think the correct understanding should be (I might be very biased though) [08:37:18.0999] something like "secondary" realm [08:37:54.0747] inb4 TertiaryRealm [08:38:03.0193] QuaternaryRealm…… [08:38:11.0289] > <@usharma:igalia.com> can someone please give cjtenny access to post? also ioanna [08:38:27.0991] The follow up candidates would be SatelliteRealm and Bubble [08:38:29.0231] Schedule shifted [08:38:51.0393] thanks Aki [08:38:56.0561] Thank you! [08:39:24.0300] SatelliteRealm has the pretty annoying double L in between. It fails to check the "easy to spell" box. [08:40:19.0295] Bubble has subjective concerns over the meaningful item and it fails the Unique box [08:40:20.0634] okay but WHY does it need to be point-free? [08:40:40.0489] a "JS bubble" search will lead to a lot of documentation over event bubble, etc [08:40:46.0827] wow, right on cue [08:40:59.0602] yup [08:41:02.0582] nicely anticipated [08:41:24.0984] eh, still not compelling [08:41:59.0092] this is a straw argument... [08:42:06.0993] you could do `$=` for all of those [08:42:08.0014] agreed [08:42:12.0395] and have basically the pipeline operator [08:44:41.0002] to be clear, I think the operator is alright, but I'm not convinced the `%` is necessary [08:45:41.0574] * to be clear, I think the pipeline operator itself is alright, but I'm not convinced the placeholder syntax (`%` in these examples) is necessary [08:45:57.0462] Michael Ficarra: pipeline is not worth it without `%` [08:46:00.0596] I think a point is that people could use `$=`…but they often don’t. Heavily nested code occurs all the time, because people make the choice between nesting versus assigning variables (whether something with a name or `$`), and it often is in favor of nesting. [08:46:09.0521] but this is hashed out on github at length [08:47:18.0610] I would prefer to have a partial application proposal. I don't see what this adds to the language other than another way to do a lot of what we can do already but in a different form [08:47:55.0389] what is the tcq code? [08:48:12.0336] Its in the reflector thread near the bottom [08:48:17.0294] ah ty [08:48:23.0850] Its not published here because this room's contents are public [08:49:03.0704] the placeholder isn't partial application tho [08:49:08.0391] * this placeholder isn't partial application tho, is it? [08:49:21.0759] it doesn't create another function [08:49:29.0304] yulia: i have concerns about readability and performance if partial application has easy to reach for syntax, personally [08:49:54.0948] ljharb i was thinking of it as a variable with a non-identifier name [08:49:59.0548] partial application also doesn't work for `await` or other keyword operators [08:50:08.0598] thats fair, we actually have similar concerns about the performance of this proposal [08:50:23.0809] oh? what performance concerns [08:50:36.0886] i thought it could be straightforwardly compiled to be using temp vars [08:50:39.0518] devsnek: anything that's not already a possible variable name is fine with me wrt that objection [08:52:22.0098] bakkot: then have special awaiting forms? [08:52:31.0069] and yield and typeof and delete? [08:52:31.0652] ugh [08:52:37.0243] that's a bunch of new forms [08:52:43.0792] instead of one general thing that just works [08:53:02.0244] shu: with the amount of potential threading we would need to do, and how it may be layered [08:53:05.0807] I just really don't think the placeholder provides any value over an arrow [08:53:14.0880] we won't block alone on this, but we still aren't convinced this is worth the cost [08:53:30.0964] yulia: not sure i understand, like it's harder to parse? [08:53:34.0073] you want to write an arrow function in each part? [08:53:35.0012] this will have a long standing impact on the languagee [08:53:42.0728] Michael Ficarra: your opinion on that question is not widely shared, as far as I can tell [08:54:07.0265] oh wow my matrix is out of sync [08:54:21.0194] devsnek: only when it's necessary [08:54:52.0156] i think it would be necessary most of the time [08:55:06.0852] literally never have i worked with a fully functional-style api in js [08:55:49.0269] I work with functions of one input and one output all the time [08:57:01.0323] shu: nah, it won't be harder to parse - we had some concerns because this will operate on expressions rather than functions and we would need to allow for both [08:57:32.0707] and we didn't think too much about it, because we blocked before and understand the "taste" aspect here about how people want to write code [08:58:13.0878] yulia: i see, if there's a concrete example i'd love to see. i'm pretty neutral to slightly negative on any and all FP proposals, to be clear, and this seemed unproblematic at first glance for implementations, but might've missed something! [08:58:58.0967] so if there is significant support here and people really want this, even though we are creating a second language on top of existing js syntax, even though there are criticisms of how pipeline works in bash and whether it was a wise addition, and in addition to the remove of partial application, then we aren't going to further complain [09:02:19.0963] > <@shuyuguo:matrix.org> yulia: i see, if there's a concrete example i'd love to see. i'm pretty neutral to slightly negative on any and all FP proposals, to be clear, and this seemed unproblematic at first glance for implementations, but might've missed something! If i get some free time and this moves forward, ill see about modifying our current version to update the new proposal... but don't know how long that will be put off due to other work [09:03:53.0371] can we please add to the notes that stage 3 will require a method extraction solution? [09:04:03.0721] i can say that out loud if needed but i don't want to slow the agenda [09:04:19.0094] it was not clear to me that we were advancing with contingent consensus [09:04:22.0888] there were several objections to that [09:04:23.0261] * can we please add to the notes that i would like stage 3 to require a method extraction solution at stage 2? [09:04:34.0081] so I am reluctant to put that in the ntoes [09:04:35.0688] the consensus today was about stage 2 advancement [09:04:52.0805] and reflects what jschoi actually said out loud already, iirc [09:04:55.0193] (It should also be clear in the notes that Hax’s current Extensions proposal does not address method extraction; it’ll have to be another extension.) [09:05:08.0427] I don't think it's right to link multiple proposals this way. My understanding of our previous discussion was more like, I personally would need to see a really strong case for both pipeline and the *infix* form of :: to both be added to the language [09:05:09.0280] * (It should also be clear in the notes that Hax’s current Extensions proposal does not address method extraction; it’ll have to be another extension.) [09:05:15.0249] jschoi: going back to something you said earlier, why do you think people don't type something like `$ =` in practice, but will type `|>`? [09:05:19.0346] method extraction has no conflict whatsoever [09:05:28.0806] is bind operator dead by now? [09:05:35.0069] but, also, we'd need to see a proposal written to make the case for it independently [09:05:35.0824] littledan and that is exactly my concern about pipeline advancing at all; i'd rather have neither than not have method extraction. [09:05:44.0384] ljharb: The coupling was always false [09:05:52.0028] I don't see how this makes method extraction harder [09:05:57.0813] the coupling is because the original `::` proposal did so [09:06:10.0154] yes, I am saying that is a false coupling [09:06:13.0924] they are just unrelated [09:06:17.0081] Michael Ficarra: I'm confused about your "point free" comment. It's absolutely pointful - the point is named `%`. F#-syntax is point-free (unless you eta-expand manually via an arrow function) [09:06:19.0075] > <@dehrenberg:igalia.com> I don't see how this makes method extraction harder i mean you literally just said "I personally would need to see a really strong case for both pipeline and the infix form of :: to both be added to the language". that's how. [09:06:30.0525] the infix form was the form that wasn't method extraction [09:06:32.0199] legendecas: The old bind operator was supposed to do many things. I already have written a proposal that addresses one of its old use cases that Hax’s Extensions don’t, method extraction. https://github.com/js-choi/proposal-method-extraction/ [09:06:34.0055] I will present it later. [09:06:35.0519] so, yes, those are related [09:06:48.0756] the prefix form was method extraction. Totally unrelated. [09:06:54.0605] * legendecas: The old bind operator was supposed to do many things. I already have written a proposal that addresses one of its old use cases that Hax’s Extensions don’t, method extraction. https://github.com/js-choi/proposal-method-extraction/ [09:07:16.0636] wait, maybe i'm confused. what do you mean by "the infix form" [09:07:50.0302] the infix form was object::function(...args), which did function.call(object, ...args) [09:08:03.0286] the prefix form was ::object.function, which did object.function.bind(object) [09:08:17.0855] the prefix form is method extraction; the infix form is more like what will be presented later this meeting [09:08:30.0968] ah ok, then yes. i think the infix form is obviated by pipeline [09:08:35.0469] I think the infix form's motivation is significantly reduced with pipeline at Stage 2, but the prefix (method extraction) is fine [09:08:42.0804] this is what I mean by false coupling [09:08:58.0118] however, we can't agree on method extraction yet, without an independent presentation on it [09:09:05.0008] shu: We know that people often don’t already write `$=` or `temp = `, because deeply nested expressions occur all the time in real code. But there seems to be strong community pressure to have some sort of pipe operator in order to be able to decompose statements into linear chains, e.g., The State of JS 2020. [09:09:38.0217] i understand that statement of fact [09:09:46.0830] i'm asking for some color and conjecture on why [09:09:56.0896] what does `%==` do [09:10:02.0039] because temp vars are gross when they aren't adding readability [09:10:11.0024] and reassigning the same var is gross because reassignment hurts readability [09:10:11.0125] but in this they are, by linearizing [09:10:20.0983] * but in this they are, by linearizing [09:10:23.0145] devsnek: `%==something` is `% == something`. [09:10:34.0639] oh, ez [09:10:35.0456] pipeline is conceptually reassigning? [09:10:37.0282] right but +linearizing -tempvars -reassignment is not a net win [09:11:06.0158] > <@shuyuguo:matrix.org> pipeline is conceptually reassigning? i can't really disagree with this, but since it's syntactic/special i think it's more like `this`, which is different from reassignment [09:11:07.0195] pipeline helps you have fluid APIs, i.e., just letting you deal with intermediaries logically, rather than assigning names to them all [09:11:21.0990] shu: Currently the only way to linearize deeply nested expressions is by assigning to temporary variables or declaring unary functions and composing them. (And the latter does not work with several kinds of operations like `yield`, of course.) [09:11:41.0906] * shu: Currently the only way to linearize deeply nested expressions is by assigning to variables or declaring unary functions and composing them. (And the latter does not work with several kinds of operations like `yield`, of course.) [09:11:45.0199] i think the confusing to me is that tab's argument was about the difficulty of coming up with unique names for all intermediates, which isn't needed [09:11:58.0424] * shu: Currently the only way to linearize deeply nested expressions is by assigning to temporary variables or declaring unary functions and composing them. (And the latter does not work with several kinds of operations like `yield`, of course.) [09:12:05.0724] in terms of color/conjecture, reusing the same name is gross - naming each step differently can be seen as more readable even though it's not needed. [09:12:15.0518] technically you need the unique names to guard against function nesting [09:12:25.0655] * in terms of color/conjecture, reusing the same name is gross - naming each step differently can be seen as more readable even though it's not needed. [09:12:47.0063] but that can be a case-by-case thing when writing the multi-variable form [09:13:03.0077] so the question is: why not use the same binding name, and the answer _seems_ to be there are, in the ecosystem there are independent reasons that reassigning to the same variable is already gross? [09:13:13.0209] i don't share that reassigning-is-gross opinion, is that a linting thing? [09:13:37.0709] i don't think any linters enforce it [09:13:43.0259] but it's def a styleguide/code review thing [09:13:45.0467] whence "it's gross"? [09:13:48.0701] > <@shuyuguo:matrix.org> i don't share that reassigning-is-gross opinion, is that a linting thing? My immediate code review would be "please create new variables" [09:13:55.0611] sure but please tell me why :) [09:13:56.0459] same, every time [09:14:11.0291] you have to understand i have like 8 general purpose regs i can work with most of the time [09:14:16.0416] my world is reassigning [09:14:18.0386] one reason is because reusing the same name means it's hard to distinguish between a bug or an intentional conflation [09:14:25.0243] same reason `let` is strongly discouraged [09:14:28.0682] * same reason `let` is strongly discouraged in favor of `const` [09:14:31.0749] wat [09:14:56.0790] My formal CS degree was with C/C++, and it's not possible to do that way [09:14:59.0856] i'm sure there's many reasons, that's just the first one that popped into my head [09:15:07.0546] ljharb: I think if you saw ``` $ = fetch(url); $ = await $; $ = await $.json(); console.log($) ``` you would not think it was a mistake [09:15:07.0703] So seeing it done feels really ikcy [09:15:26.0277] bakkot: agree, but it still looks gross to me subjectively/aesthetically [09:15:38.0307] that code is difficult for me to process [09:15:39.0888] > <@ljharb:matrix.org> same reason `let` is strongly discouraged in favor of `const` sidebar: I wish you would phrase these things as "I strongly discourage `let`", not "`let` is strongly discouraged" [09:15:47.0028] as I'm sure you are aware, not everyone shares that opinion [09:15:53.0140] sure. but it's not just me that has that opinion. [09:15:56.0696] reassigning would get kicked out of any codebase I have ever worked on [09:16:01.0930] "let is strongly discouraged by many", if you require the qualifier [09:16:02.0850] because i need to stop for a moment and mentally remove the assignment and only focus on the right hand sides [09:16:38.0741] I do this in Rust every now and then: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5cffe97b80fea645eb3a34b711d36ad6 [09:16:42.0276] I've more than once heard people say that `const` names can be better optimized by the engine and therefore you shouldn't use `let` [09:17:19.0488] that is definitely not true [09:17:23.0311] I feel like reassigning is sort of logically more complicated than having a nested expression or chain of method calls. You have to think about what else might be affected, instead of just seeing the single use in the expression tree. [09:17:27.0625] whenever i've heard that i've pointed out that a) you can't know that unless you look at the engine's code and/or benchmark it, and b) perf doesn't matter, clarity does [09:17:46.0282] I didn't say I believe that, I'm saying it's an idea that's out there [09:17:55.0697] "perf doesn't matter" is, uh, also a strong claim which maybe should be qualified [09:18:04.0273] I think many devs have learned not to reassign because that smells like global variable, bug farm code. And so socially it's not done unless it can be proven it's more performant or someone who likes it has the power on that codebase. [09:18:30.0709] sarahghp: thanks, that's helpful [09:18:45.0231] i mean, i disagree with it, but that's helpful [09:19:17.0084] You disagree with my description of experience or you think people shuldn't think that? [09:19:23.0391] the latter [09:19:58.0817] well, I guess as language designers, we're sort of co-creators in this shared, socially constructed reality [09:20:07.0923] is this an accurate summary: it is easier to try for higher quality code to forbid reassignment stylistically, and that's of higher priority even though it takes out "linearization via reusing the same temp var" as collateral [09:20:24.0235] but at the same time, linearization is also good style [09:20:24.0554] the culture of usage patterns is just as much co-creation, alongside the definition of the language [09:20:30.0362] so we should do pipeline? [09:20:59.0613] to be clear, my disagreement is it's just fine to carve an exception for "reassignment is bad, except when linearizing" [09:21:07.0414] but also, pipeline helps with things like Object.fromEntries, where otherwise you have to nest [09:21:08.0931] or react HOCs [09:21:22.0370] Sorry quick aside, did hack-style pipelines reach stage 2? I wasn't really clear [09:21:26.0962] yes [09:21:33.0143] but people really want to type what they want to type, and that's fine too, i don't have too much skin in the game [09:21:53.0532] the compiler's going to turn it into a reassignment for you anyway [09:22:10.0371] `Component |> withC(%) |> withB(%) |> withA(%)` or `Object.entries(o).map(…) |> Object.fromEntries(%)` are much clearer than `withA(withB(withC(Component)))` or `Object.fromEntries(Object.entries(o).map(…))`, or the temp var equivalents [09:22:24.0836] i disagree? [09:22:26.0174] > <@shuyuguo:matrix.org> is this an accurate summary: it is easier to try for higher quality code to forbid reassignment stylistically, and that's of higher priority even though it takes out "linearization via reusing the same temp var" as collateral Yes. [09:22:28.0454] the compiler turns it all into electricity anyways, "what the compiler does" doesn't matter [09:23:02.0178] especially the withA/B/C example, how is `Component |> withC(%) |> withB(%) |> withA(%)` clearer? [09:23:13.0630] I am not at all convinced that it's actually that much more clear than ``` let $= Component; $= withC($); $= withB($); withA($); ``` [09:23:28.0969] no one writes that, of course, but no one writes `|>` either, so [09:23:32.0820] shu: I think it becomes clearer if postfix or circumfix operations (like array wrapping or function calls with following arguments) get involved, so that you no longer have to switch between LTR and RTL reading. [09:23:34.0917] > <@shuyuguo:matrix.org> especially the withA/B/C example, how is `Component |> withC(%) |> withB(%) |> withA(%)` clearer? In this style, the order you read is the order of execution. [09:23:39.0494] > <@ljharb:matrix.org> the compiler turns it all into electricity anyways, "what the compiler does" doesn't matter Welcome to TC39, where the points are made up, and what the compiler does doesn't matter [09:23:46.0097] * shu: I think it becomes clearer if postfix or circumfix operations get involved, so that you no longer have to switch between LTR and RTL reading. [09:24:07.0710] whose pipeline is it anyway [09:24:10.0228] the "order of execution" thing is weird to me [09:24:21.0944] like, presumably the folks who want this are FP enthusiasts [09:24:22.0755] * shu: I think it becomes clearer if postfix or circumfix operations (like array wrapping or function calls with following arguments) get involved, so that you no longer have to switch between LTR and RTL reading. [09:24:25.0809] well, it's what I really loved about Factor and postfix langauges in general! [09:24:35.0555] and also what I think many people love about method-chaining APIs [09:24:46.0657] yet a major selling point here is that they find function composition and order of function application confusing, and there should be new syntax to make it look imperative? [09:24:49.0387] i am very much not an FP enthusiast in that way, i think RxJS-style coding is harder to understand. and i very much want pipeline for my not-super-FP but not-OO code. [09:25:04.0405] When the compiler reassigns it, it is in special compiler land, where Bill from four departments over isn't going to do something weird with it and bring the site down. [09:25:07.0030] stack-based languages (and some FP enthusiasts) get way too obscure since they try to juggle multiple things in the pipeline. don't do that. [09:25:14.0395] the people who want the *other* pipeline syntax, the point-free one or whatever it's called, are definitely FP enthusiasts [09:25:34.0523] I am an FP enthusiast, and I like pipes. But I would like pipes to handle multiple arguments as well as they do unary calls. And non-function-call expressions too. [09:25:37.0980] You can think of the pipeline as ShadowRealm reassignment maybe. (Warning: May not actually understand Shadow Realms.) [09:25:52.0143] Stage 2 on Pipeline Operator is kind-of a big deal... I would have liked to have seen a lot more data and surveys about how this will impact practitioners and code readability in the long term. We have the TC39 Research Call for this exact purpose, but Pipeline Operator has not been a subject of that call, at least not for a long time. Stage advancement seemed rushed. [09:25:57.0888] we found out apparently Shadow Realm was a euphemism put in in the Yugioh dub to soften the concept of "death" [09:26:01.0502] jschoi: so use arrows? [09:26:01.0892] * I am an FP enthusiast, and I like pipes. But I would like pipes to handle multiple arguments as well as they do unary calls. And non-function-call expressions too. [09:26:28.0002] * You can think of the pipeline as ShadowRealm reassignment maybe. (Warning: May not actually understand Shadow Realms.) [09:26:33.0008] Yes, arrows, but they don’t work with function-scoped operations and they still require argument naming. Which is presumably why deeply nested code still happens in real life (naming is hard, etc.). [09:26:45.0400] * Yes, arrows, but they don’t work with function-scoped operations and they still require naming. Which is why deeply nested code still happens in real life. [09:26:55.0696] * Yes, arrows, but they don’t work with function-scoped operations and they still require argument naming. Which is presumably why deeply nested code still happens in real life. [09:27:00.0904] * Yes, arrows, but they don’t work with function-scoped operations and they still require argument naming. Which is presumably why deeply nested code still happens in real life (naming is hard, etc.). [09:27:06.0891] nobody wants to join the hallway track? [09:27:16.0786] jschoi: when the scope of the variable is a single line, the names don't matter [09:27:19.0531] just use a single letter [09:27:26.0611] or `$` as suggested above [09:27:55.0569] > <@shuyuguo:matrix.org> we found out apparently Shadow Realm was a euphemism put in in the Yugioh dub to soften the concept of "death" huh.... this seems pretty bad [09:28:08.0650] euphemism isn't the right word [09:28:17.0872] but you know how they change stuff when they dub anime for a US audience? [09:28:21.0485] like they'd removal cigarettes, etc [09:28:33.0984] euphemism is what it says on the wiki [09:29:05.0896] https://i.kym-cdn.com/photos/images/newsfeed/001/069/615/189.jpg [09:29:31.0734] > <@sffc:mozilla.org> Stage 2 on Pipeline Operator is kind-of a big deal... I would have liked to have seen a lot more data and surveys about how this will impact practitioners and code readability in the long term. We have the TC39 Research Call for this exact purpose, but Pipeline Operator has not been a subject of that call, at least not for a long time. Stage advancement seemed rushed. Huh, maybe some kind of research could be proposed as a request of the champion group for Stage 3? But if this request is made, it'd help to understand what the research question should be. [09:29:34.0022] i think euphemism is the correct word [09:29:54.0772] Michael Ficarra: Yes, but arrow functions with single-char variables still don’t address function-scoped operations, and they’re more verbose. And that verbosity is also perhaps much of why people don’t linearize deeply nested expressions more often. [09:30:30.0352] > still don’t address function-scoped operations [09:30:32.0664] what does this mean? [09:30:38.0591] `yield` and `await`. [09:31:10.0666] oh, yes, I think the pipeline proposal should have an awaiting pipe variant [09:31:59.0835] it does? [09:32:04.0893] you can just do that [09:32:11.0290] didn't mark propose a syntax for building up async chains [09:32:30.0883] littledan: michael is in favor of F#-style [09:32:39.0214] with a special `await` form [09:32:49.0491] yeah, I proposed that in the past and people continued to be unhappy [09:33:03.0195] I think Hack is a good general way forward. I'm glad we agreed to Stage 2 on it. [09:33:15.0158] > <@devsnek:matrix.org> didn't mark propose a syntax for building up async chains Is it the `~.` operator? [09:33:51.0307] I guess I'm seeing a lot of advancements this meeting where people express unhappiness *afterwards*. This seems pretty unfortunate process-wise. I'm wondering what's preventing the concerns from being expressed before/during the call for consensus. [09:34:17.0140] do we need to punt more agenda items to next meeting, for example? [09:34:20.0054] "blocking" has high social cost? [09:34:27.0959] specifically, lone blocking [09:34:34.0684] > <@bakkot:matrix.org> with a special `await` form Wavy dot [09:34:45.0503] all of the comments about this topic were expressed as "if everyone else supports it" [09:34:53.0129] https://github.com/tc39/proposal-wavy-dot [09:35:12.0567] well, I previously proposed that we have `|> await` usable within an F# pipeline [09:35:12.0698] > <@dehrenberg:igalia.com> Huh, maybe some kind of research could be proposed as a request of the champion group for Stage 3? But if this request is made, it'd help to understand what the research question should be. I think there are legitimate concerns about the long-term impact of any radically new syntax in JS. Designing the exact research question is something Felienne et al can help us do in the TC39 Research Call [09:35:18.0058] littledan: I think we need a better process for advancement than taking the last two minutes of a timebox to ask if anyone is going to block [09:35:28.0150] that's like the maximally pressure-to-stay-silent situation one could devise [09:35:29.0787] well, I've proposed that we ask for explicit support [09:36:12.0052] we could say, everything needs to be nominated and seconded, and then we have an explicit (e.g., minimum 15 second) time to call for objections [09:36:22.0078] littledan: for this proposal, there are plenty of people willing to voice explicit support though [09:36:28.0111] I think that addresses a different kind of issue [09:37:09.0010] well... I'm happy that this proposal went through. I'm not sure what we would want process-wise. I'd be fine with spending more time understanding people's objections, but I'm also up for it eventually going through. [09:37:10.0611] the issue here is the presence of a lot of negative sentiment as well [09:37:58.0171] I think we should spend more time within Stage 2 more clearly communicating the concrete concerns that delegates have. I honestly don't understand, e.g., what Mozilla's concerns are. [09:38:16.0058] yeah, specifically, the problem is that if 10% of people like a proposal and 90% of people don't think it's worth it (or think it needs more time or research or whatever) but none of them enough to stand up and say "I am blocking this", then it will advance [09:38:46.0627] I think support among JS developers is much higher than 10%... [09:38:47.0080] is that a problem though? [09:39:03.0298] if no one wants to block it then it shouldn't be bad enough to be a problem [09:39:14.0563] I guess I'd be worried if pipeline had a lot of big implications for JS syntax, semantics, or implementation. This one is pretty lightweight, even if it does have some syntax. [09:39:34.0523] littledan: support for _some form_ of pipeline, yes. it is not clear to me that any particular instantiation has support higher than 50% [09:39:55.0910] or, concretely, that _this_ instantiation has support higher than 50% [09:39:59.0634] littledan: mozilla's concern seems to be broadly, "negative readability in the ecosystem in the future" [09:40:00.0885] I believe there are still many concerns about the direction of pipeline op proposal. It seems fp guys who use Ramda heavily and rx guys actually don't like Hack style... [09:40:08.0752] OK, I suggest that we should keep discussing the pros and cons of the forms during Stage 2 [09:40:13.0671] i also do not understand what their implementation concerns are [09:40:17.0976] there's a channel for this that everyone can join [09:40:49.0356] the current "default" proposal is Hack, but we're still allowed to make changes until Stage 3 [09:41:24.0559] Stage 2 with Hack style already give a signal that champions choose Hack style... [09:42:01.0249] > I think support among JS developers is much higher than 10%... also, actually, I think I disagree with this claim as stated, even aggregating the two forms. I doubt more than 10% of JS developers have even heard of it. [09:42:05.0787] * > I think support among JS developers is much higher than 10%... also, actually, I think I disagree with this claim as stated, even aggregating the two forms. I doubt more than 10% of JS developers have even heard of it. [09:42:10.0303] * > I think support among JS developers is much higher than 10%... also, actually, I think I disagree with this claim as stated, even aggregating the two forms. I doubt more than 10% of JS developers have even heard of it. [09:42:18.0940] > <@dehrenberg:igalia.com> there's a channel for this that everyone can join Is it public? I can search nothing for pipeline rooms on freenode nor matrix [09:42:45.0959] I think Dan meant the issue tracker? legendecas [09:43:30.0475] i think the only complexity for implementations is nesting `%` in functions, and that can still just be like pushing a scope if the thing is closed over [09:43:56.0291] > <@legendecas:matrix.org> Is it public? I can search nothing for pipeline rooms on freenode nor matrix it's public and in the TC39 Matrix space [09:44:00.0672] > <@bakkot:matrix.org> > I think support among JS developers is much higher than 10%... > > also, actually, I think I disagree with this claim as stated, even aggregating the two forms. I doubt more than 10% of JS developers have even heard of it. There is a poll on State-of-JS, and pipeline op is the fourth wanted, but the problem is which style? the poll did not show the choices, and I guess most people who choose pipeline op actually only know F# style. [09:44:19.0874] i do not have confidence in the State of JS poll [09:45:26.0339] HE Shi-Jun: significantly less than 10% of js devs take that poll, and I strongly suspect that those who do are not a representative sample [09:45:33.0154] * HE Shi-Jun: significantly less than 10% of js devs take that poll, and I strongly suspect that those who do are not a representative sample [09:46:07.0835] > <@shuyuguo:matrix.org> i do not have confidence in the State of JS poll Yeah, what I said is, even people who did State-of-JS poll may only choose F# style, not Hack style which we move to stage 2 now. [09:47:32.0881] Actually, Hack style is very rare , I only know Hack use it (are there others?) and Hack is not a popular language. [09:47:47.0927] is F# a popular language? [09:48:09.0819] HE Shi-Jun: topic variables are used in a number of languages; see https://rosettacode.org/wiki/Topic_variable [09:48:21.0127] hack-style is basically "introduce a context in which there is a topic variable" [09:48:22.0971] if I was the champion of this proposal, I wouldn't want it to advance to stage 2 with the current committee sentiment [09:49:32.0627] then i would recommend someone re-raise the issue if they feel strongly enough. for better or for worse our process isn't temperature based [09:49:52.0871] on the process question, I would kind of like something like, "no blockers, and at least a 60-40 ratio of support for advancing now among members [given a neutral option which counts as neither]" or something like that [09:50:34.0063] I have no stake in this proposal myself, but to be honest I'm uncomfortable with delegates seeding this much doubt upon proposals that advanced, right after allowing them to advance. [09:50:36.0518] i would not want to consider blocking and ratio in the same context [09:50:55.0751] > <@bakkot:matrix.org> hack-style is basically "introduce a context in which there is a topic variable" I mean use special token/syntax like Hack. I don't treat special identifier (for example, Kotlin's `it`) as Hack style. [09:50:57.0990] invited you to the channel; anyone else here, feel free to request an invitation [09:51:06.0064] > <@legendecas:matrix.org> Is it public? I can search nothing for pipeline rooms on freenode nor matrix * invited you to the channel; anyone else here, feel free to request an invitation [09:51:46.0332] ptomato: see https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$JYBpReC9kRacMt_lOYbire_ID6halPslhWB0qzG6Ztk?via=matrix.org&via=mozilla.org&via=igalia.com [09:51:59.0796] > I think we need a better process for advancement than taking the last two minutes of a timebox to ask if anyone is going to block > that's like the maximally pressure-to-stay-silent situation one could devise [09:52:07.0809] I would be in favor of a reform of TC39 where we do frequent non-binding polls of the committee like the Wasm CG does, so we can get more of a temperature. However, when I proposed this in the past, much of the committee was opposed and preferred to stick to the objection-based model, I guess because there was fear that such polls would be used to push past objections (sort of the inverse of this case) [09:52:34.0877] I feel if you have serious doubts about a proposal, then block it and work with the champions to resolve those doubts. it's true there is a social cost for single-handedly blocking a proposal, but that's by design. you shouldn't get to 'block lite' retroactively by seeding doubts without paying the social cost [09:52:36.0462] I wouldn't mind at all making more frequent use of the temperature check feature, even if it's for each consensus [09:52:46.0624] in rfc7282 they do humming [09:52:58.0579] littledan: yeah, that's why I suggest having an additional requirement, rather than removing the current requirement [09:53:06.0681] tbh i think we should read through rfc7282 at the start of every meeting, it's not too long and its great [09:53:13.0798] I do think we need better ways of taking non-blocking concerns into account. However, I think the champions did their homework here and there's nothing to change. [09:53:15.0541] > <@haxjs:matrix.org> I mean use special token/syntax like Hack. I don't treat special identifier (for example, Kotlin's `it`) as Hack style. Actually Kotlin's soutlion (https://rosettacode.org/wiki/Topic_variable#Kotlin) is extensions not pipeline op. [09:53:45.0549] ptomato: right, but what if you, and 50% of the other committee, have only moderate doubts about a proposal, and the timebox expires before you raise them [09:53:51.0352] * ptomato: right, but what if you, and 50% of the other committee members, have only moderate doubts about a proposal, and the timebox expires before you raise them [09:53:58.0200] (not claiming that's what happened here, just raising that it can happen) [09:54:08.0171] then the discussion isn't finished and there's no consensus? [09:54:11.0620] well, maybe we should avoid shortening the timeboxes this meeting, and just cover fewer topics [09:54:21.0876] if the consensus decisions will keep being questioned afterwards [09:54:50.0772] there's a practical question here for pipeline [09:55:20.0197] out of all the delegates with moderate concerns and negative sentiment: do you think you'll block a stage 3? if it's trending that way, best surface that now [09:55:23.0175] this really isn't a healthy discussion style, of seeding doubt later about what stage things are really at. [09:55:47.0251] i agree, that's why i think folks should take stock of how strongly they feel and raise it now [09:55:50.0520] or hold their peace [09:56:25.0428] i don't feel very comfortable objecting again as I did that before and was a lone objector. I am still not super happy with this solution but i can deal [09:56:45.0964] +1 to what Shu said. I *absolutely* want to surface, deal with, and address concerns sooner rather than later. I wanted to settle on the syntax-choice, and afaict once that was done we were in an appropriate place for stage 2, but stage 3 definitely shoudln't be reached until we generally have the committee happy [09:57:20.0805] TabAtkins: the committee will not generally be happy with any solution here, I am pretty sure [09:57:23.0185] including not advancing [09:57:30.0534] hehe [09:59:56.0174] is it time for iterator helpers blitz update [10:01:07.0229] yeah [10:03:29.0844] can't see slide ? [10:03:39.0260] I don't think there are slides? [10:03:45.0958] can see slide now [10:03:57.0359] i see this https://gc.gy/7eb4bbb4-9e91-4496-b159-45c6e872d4bf.png [10:04:04.0120] oh wait _I_ don't see slides [10:04:08.0184] that was so fast! [10:04:20.0731] shu no [10:04:23.0816] generator return is good [10:04:36.0493] i do not like it [10:04:46.0558] 😭 [10:06:04.0867] What is generator return? [10:06:07.0748] this was one of my first things in TC39, where I proposed 1) Get rid of subclassing RegExps 2) Get rid of generator return [10:06:15.0320] `.return` on generators [10:06:16.0142] cool to see Shu and Yulia pick up those threads years later [10:06:20.0307] injects a return completion at `yield` [10:06:30.0813] `throw` is the better example though probably; it comes up much more [10:07:05.0854] generator return is key for doing... something [10:08:16.0828] cleaning up resources, primarily [10:08:21.0835] which still seems like it's important to me [10:08:40.0591] ``` function* foo() { yield 1; return 2; } // undefined it = foo() // foo {} it.next() // {value: 1, done: false} it.return(3) // {value: 3, done: true} ``` [10:08:40.0745] IteratorClose calls `.return` [10:08:43.0044] What! [10:09:16.0317] oh right iteratorclose calls it [10:09:21.0043] i knew it did something [10:10:04.0105] if no `return` it will have memory leak [10:10:50.0359] that depends very highly on what the iterator is doing tho, no? [10:11:09.0366] HE Shi-Jun: i think i was wrong there let me get back to you [10:11:14.0790] ljharb: if it does not have any resources which need to be cleaned up, sure, it won't leak, tautologically [10:11:18.0046] if it does, it will [10:11:46.0015] we may still pass the next value, i missed the follow up convo, and it looks like we may be primarily looking at throw and return [10:11:54.0193] > <@yulia:mozilla.org> HE Shi-Jun: i think i was wrong there let me get back to you oh! [10:11:58.0550] specifically: https://github.com/tc39/proposal-iterator-helpers/issues/122#issuecomment-866811008 [10:14:22.0297] yulia: I still not fully get what the changes of iterator-helpers , i need some time to read the issue carefully 😅 [10:14:35.0095] hmm, no i think indeed, to pass the yield from next the suggestion was to have a method that calls out that behavior... HE Shi-Jun can you point me to your concern in double ended iterators? [10:15:00.0583] that is, how it would use the yield [10:15:26.0709] (also good to have this discussion) [10:16:14.0853] as a concrete example, calling `.return` on the iterator for a whatwg ReadableStream will close it, which can release e.g. network resources. if `for await (let chunk of stream[Symbol.asyncIterator]().map(x => x) break;` does not close the stream, that seems bad. [10:16:21.0194] I guess I should post that on the issue. [10:17:03.0601] looks like domenic has a similar concern... [10:17:23.0446] hah, he literally just posted that, excellent [10:18:08.0626] `let streams_fr = new FinalizationRegistry((stream) => stream.dispose())` 🤡 [10:18:18.0181] this was the original reason that domenic and i wanted passing the protocol [10:18:28.0127] bakkot: is it ok if i quote your comment? [10:18:32.0985] yulia: go for it [10:18:42.0604] though I think it's just what domenic said [10:19:05.0879] domenic didn't say it cleans up a network request [10:19:12.0424] which is very motivating imo [10:19:20.0264] > <@yulia:mozilla.org> hmm, no i think indeed, to pass the yield from next the suggestion was to have a method that calls out that behavior... HE Shi-Jun can you point me to your concern in double ended iterators? deiter rely on `param` in `next(param)`. So if iterator helpers pass the param then `let [a, ..., b] = [1,2,3].values().map(x => x*x)` just works (a will be 1, b will be 9) [10:19:32.0348] ok, ill quote that in as well [10:20:16.0649] yulia: Note last time I checked iterator helpers, there is a issue that the first next(param) call is missing. [10:20:20.0094] yulia: fwiw i continue to have zero idea what "pass the protocol" means, every time i see it; i wonder if there's a clearer phrasing that could be used to discuss that issue? [10:20:54.0183] passing the protocol is referring to passing the iterator protocol, that is `return`, `throw`, and that `next` takes a value [10:21:06.0284] "implementing the extended iterator protocol" [10:21:25.0680] you can pass a first-class thing, a protocol is not a first-class thing, so it confuses me (because you can't actually pass a protocol, eg) [10:21:27.0695] good feedback, thank you everyone [10:21:41.0973] Oh yeah, I didn't read "pass the protocol" as meaning "implement" either, I thought it was about argument-passing something. [10:22:15.0644] well, streams would "work" if you need an opt in as an argument [10:22:20.0552] that would be a pretty clunky API though i suppose [10:22:45.0194] * you can pass a first-class thing, a protocol is not a first-class thing, so it confuses me (because you can't actually pass a protocol, eg) [10:22:49.0579] “Delegating to the protocol” perhaps? [10:37:05.0821] ljharb: > a protocol is not a first-class thing not yet! [10:37:52.0707] jschoi: would you be able to present asyncFrom at ~15:20? [10:37:55.0384] Michael Ficarra still super waiting for you to bring it back to committee [10:38:42.0923] ditto [10:38:47.0009] bterlson: I can do it. Would a chair be able to manage the slides for me? [10:40:07.0727] i want the protocol proposal [10:40:08.0477] jschoi: I can help with that sure. You just need me to present them? [10:41:10.0909] ljharb yulia devsnek: I would love to, I just need more time to do it [10:41:30.0790] maybe after this term as editor, I will feel satisfied with the state of the spec and replace that work with protocols proposal work [10:41:37.0459] true facts about tc39 delegates [10:41:46.0917] bterlson: Yeah, but I can try screen sharing myself first. I just might run into problems. [10:41:52.0179] * true facts about tc39 delegates ("would love to, need more time") [10:41:57.0528] > <@michaelficarra:matrix.org> maybe after this term as editor, I will feel satisfied with the state of the spec and replace that work with protocols proposal work there's so much to be done yet... [10:42:04.0124] jschoi: ok no problem, I will be able to present if you cannot. [10:42:04.0348] though it is finite, at least [10:42:23.0408] bakkot: yes, it's unlikely; probably after the *next* term [10:46:09.0787] i do not love having a meaningfully different third mode [10:46:31.0255] I was hoping `v` would just be `u` with some tiny changes to syntax you weren't using, like `&` [10:46:45.0860] having it change the semantics of `\d` seems like a whole new mode to learn [10:46:59.0212] * I was hoping `v` would just be `u` with some tiny changes to syntax you weren't using, like `&&` [10:47:01.0464] bakkot: same, I am not so sure about this [10:53:36.0522] sometimes making everything better isn't actually better [10:55:25.0818] it is a new mode, the one described by https://www.unicode.org/reports/tr18/ [10:58:07.0902] does any language actually implement the full unicode regexes as specified in tr18? [10:59:32.0671] Ah, meant to add my topic as a discussion of the last topic. No problem though [11:02:18.0309] By "inline modifiers", I meant `(?u-v:\d)` [11:03:01.0774] as in: https://rbuckton.github.io/regexp-features/features/modifiers.html [11:05:12.0253] I think it would be productive if there were specific examples of breakage, since this is an opt-in option. [11:05:22.0304] Oh, someone’s bringing it up now. [11:05:54.0643] > <@jschoi:matrix.org> I think it would be productive if there were specific examples of breakage, since this is an opt-in option. I could see someone wanting ASCII `\d` along with set notation. [11:06:27.0088] But they could just write `[0-9]` [11:06:30.0630] sorry i was afk, in what language is \d not [0-9]? [11:08:03.0035] ICU, at least, specifies `\d` to "Match any character with the Unicode General Category of Nd (Number, Decimal Digit.)" [11:08:22.0884] ok but i'm asking in what practical implementations will a user type `\d` and not expect `[0-9]` [11:08:29.0990] * ok but i'm asking in what practical implementations will a user type `\d` and not expect `[0-9]`? [11:08:30.0541] * ok but i'm genuinely asking in what practical implementations will a user type `\d` and not expect `[0-9]`? [11:09:52.0790] People writing applications that use the ICU regex API in C++. I think some Apple APIs expose it, from what I recall? [11:09:53.0829] https://unicode-org.github.io/icu/userguide/strings/regexp.html [11:10:13.0890] * People writing internationalized applications that use the ICU regex API in C++. I think some Apple APIs expose it, from what I recall? [11:10:24.0999] * People writing internationalized applications that use the ICU regex API in C++. I think some Apple APIs expose it for that purpose, from what I recall? [11:10:36.0799] C++ regex is specified by reference to ecmascript, fun fact [11:10:43.0908] so `\d` means [0-9] [11:11:04.0314] * C++ regex is specified by reference to ecmascript, fun fact [11:12:22.0190] I think if `\d` means `[0-9]` in literally every language that has regexes, we should not introduce a new mode where it means something else. [11:12:41.0802] if we want to expose a matcher which means a different thing, we can pick a new name for it. [11:14:28.0803] Python `\d` `\s` `\w` are only limited to ASCII in the presence of a flag: https://docs.python.org/3/library/re.html [11:14:53.0144] ah, that's a good data point [11:15:16.0779] I've updated https://rbuckton.github.io/regexp-features/engines/icu.html#feature-character-class-escapes, I'm checking if my comparison is missing anything for the other engines I've added so far. [11:16:22.0793] bradleymeck: let me put it a different way than "silent": if I use `\v`, it's going to be because I want to use `&&`, and I am not going to expect it to also change `\s` [11:16:38.0085] Oniguruma uses `Decimal_Number` in unicode mode [11:17:53.0997] * bradleymeck: let me put it a different way than "silent": if I use `/.../v`, it's going to be because I want to use `&&`, and I am not going to expect it to also change `\s` [11:18:55.0919] so for the conclusion, was there any support for any of the discussed changes? [11:18:56.0210] bakkot: that doesn't make it silent/implicit though [11:19:14.0701] i would love if stuff like \s matched more than ascii [11:19:15.0411] although JS is interesting in having ASCII-only `\d` `\w` but Unicode-aware `\s` [11:21:06.0824] can we just have like [11:21:09.0246] a `/good` flag [11:21:21.0700] that enables all the good unicode and sets and unicode selectors and etc [11:21:44.0766] `/gud`! [11:21:58.0217] not even joking i want a flag that just does it all [11:22:07.0497] `const goodRegex = /good/👍;` [11:22:13.0270] `/U`, it's unicode but taller [11:22:13.0998] * 1st const goodRegex = /good/👍 ;` [11:22:24.0708] * `const goodRegex = /good/👍 ;` [11:22:29.0778] that's basically what `/v` is currently proposed to be (or are you commenting specifically on how it is spelled?) [11:22:40.0855] * `const goodRegex = /good/👍;` [11:22:48.0291] apologies, that belonged in TDZ instead of here :-) [11:22:57.0951] > <@gibson042:matrix.org> that's basically what `/v` is currently proposed to be (or are you commenting specifically on how it is spelled?) i dunno it sounds like `\w` might only match ascii word characters? [11:24:34.0114] the current proposal is for `\v` to align with https://www.unicode.org/reports/tr18/ , including set operations and Unicode-aware and -compliant `\d` `\s` `\w` `^` `$` [11:24:50.0767] but it sounds like there is not consensus for that [11:25:25.0153] yeah that's what i would want [11:25:56.0733] Richard Gibson: "not consensus" is quite the understatement there [11:26:57.0213] idk why anyone would want to keep having the bad versions of these character classes [11:28:14.0773] Another data point: https://perldoc.perl.org/perlunicode [11:28:51.0507] Michael Ficarra: throwing [11:28:59.0591] Also, .NET has `\d` match `\p{Nd}` unless in "ECMAScript-compliant" mode [11:29:11.0330] * forcing me to `coerce(x) === x` sucks versus `isGood(x)` [11:29:20.0584] * Michael Ficarra: throwing. forcing me to `coerce(x) === x` sucks versus `isGood(x)` [11:29:26.0621] * Another data point: https://perldoc.perl.org/perlunicode https://www.perl.com/pub/2012/05/perlunicook-disable-unicode-awareness-in-builtin-character-classes.html/ [11:30:24.0335] Many (but not all) of the languages/engines I've been looking at only seem have `\d` match `[0-9]` for ECMAScript compatibility. [11:31:06.0573] * Another data point: https://perldoc.perl.org/perlunicode https://www.perl.com/pub/2012/05/perlunicook-disable-unicode-awareness-in-builtin-character-classes.html/ Perl 5.14 in fact has an opt-*out* flag (`/a`)for making \d ASCII-only. [11:31:16.0047] * Another data point: https://perldoc.perl.org/perlunicode https://www.perl.com/pub/2012/05/perlunicook-disable-unicode-awareness-in-builtin-character-classes.html/ Perl 5.14 in fact has an opt-*out* flag (`/a`)for making `\d` ASCII-only. [11:31:32.0079] * Another data point: https://perldoc.perl.org/perlunicode https://www.perl.com/pub/2012/05/perlunicook-disable-unicode-awareness-in-builtin-character-classes.html/ Perl 5.14 in fact has a Unicode opt-*out* flag (`/a`), for making `\d` ASCII-only. [11:32:50.0653] Michael Ficarra: per my queue item, streaming seems like it definitely needs the predicate [11:33:02.0554] you want to slice off the surrogate and buffer it for the next chunk, or just wait, but you don't want to replace [11:33:12.0444] like you keep the buffer around and wait for the other part of the surrogate to come in? [11:33:18.0703] yeah, up to the impl [11:33:20.0019] yeah [11:33:21.0080] but you don't want to replace [11:33:33.0716] yeah I'm definitely convinced sufficiently for stage 1 [11:33:58.0465] would've been nice for the proposal to include these kinds of motivations [11:34:02.0662] can't see the slide [11:43:07.0107] regarding toArray in iterator-helpers, I hope to expand it in the future to be able to build more kinds of structures (adding a protocol like Buildable or Ana) [11:43:39.0766] oh jeeze please do not gate this proposal on cancelation [11:44:11.0045] cancellation is a simple problem with a clear solution [11:44:11.0288] most definitely please do not [11:44:35.0083] Don't want to gate, do want to consider it though. [11:44:59.0161] I agree with you that cancelation would be good, I just despair of trying to go through that agian [11:45:02.0216] * I agree with you that cancelation would be good, I just despair of trying to go through that again [11:45:17.0439] > <@devsnek:matrix.org> cancellation is a simple problem with a clear solution Can you elaborate? Biggest problem we have with `AbortSignal`/`AbortController` is the dependence on `EventTarget`. [11:45:25.0598] also the name "abort" is bad, but +1 that let's please not get into that again [11:45:26.0852] oh sorry i was being sarcastic [11:45:34.0129] * also the name "abort" is bad, but +1 that let's please not get into that again [11:45:36.0732] > <@michaelficarra:matrix.org> regarding toArray in iterator-helpers, I hope to expand it in the future to be able to build more kinds of structures (adding a protocol like Buildable or Ana) should this be a to or is a better pattern this [11:46:11.0332] because i agree that this should be general and i am wondering what thee best pattern will bee here [11:46:12.0986] I've been meaning to follow up on https://github.com/tc39/proposal-cancellation/issues/22 for a while, but priorities shifted. [11:46:25.0413] i'm hearing profits for azure! [11:46:27.0058] what's the problem [11:46:44.0353] yulia: good question! I considered both and settled on the latter, but I can't remember the details of why. Let me get back to you. [11:46:46.0900] what i like about using iterator helpres is that we can use take(n), and then this is already scoped [11:46:47.0411] * I've been meaning to follow up on https://github.com/tc39/proposal-cancellation/issues/22 for a while, but priorities shifted. [11:47:15.0065] `.fromAsync_IKnowThisCanBeExpensive` [11:47:22.0285] That scopes by size, but not by time [11:47:41.0716] `.takeWhile` would let you scope by time! [11:47:49.0192] you could say `.take(10)` and the 9th element could take minutes. [11:48:15.0241] `.takeWhile(() => (new Date) - start < 1000) [11:48:17.0085] * `.takeWhile(() => (new Date) - start < 1000)` [11:48:19.0260] Even `.takeWhile` needs to wait for the async element to complete before its evaluated. [11:48:27.0484] ah, fair point [11:49:00.0650] So while that would work for `Promise.race()`, you still leave the array and promise allocations in memory until it eventually completes. [11:50:24.0704] The main reason I never moved forward with https://github.com/tc39/proposal-cancellation/issues/22 was that it needed a compelling reason to exist (i.e., something in the JS core language that needed cancellation). Between this and `.waitAsync` there are now at least two compelling cases. [11:52:26.0348] Upside of #22 is it just provides a protocol for cancellation that can be implemented by existing cancellation primitives (AbortController in DOM/Node, CancellationToken in VSCode, etc.) and makes them fairly interoperable, without introducing an actual cancellation primitive into the language. [11:53:41.0005] revoked proxies lul [11:57:41.0534] in case you didn't know, proxies for callables are callable [12:13:33.0698] yulia: I remembered why it's better for a buildable structure to consume an iterable than for an iterable to consume a buildable protocol [12:15:21.0177] sometimes building something one element at a time is the same as building it >1 element at a time, but sometimes it could be slow to build that way or produce a structure with equivalent semantics but different performance properties [12:15:35.0817] so it's best for the buildable thing to control how it consumes the iterable [12:22:46.0931] something like discussed here: https://github.com/tc39/proposal-iterator-helpers/issues/36 [12:52:26.0975] Regarding how other engines treat `\w`, `\d`, and `\s`, I've updated each engine's support at https://rbuckton.github.io/regexp-features/features/character-class-escapes.html with more thorough documentation. On the whole, most engines I've researched treat `\w`, `\d`, and `\s` as including unicode characters unless an ASCII-specific setting (or "ECMAScript compatibility" mode) is enabled. This includes Perl, .NET, Oniguruma, and ICU. PCRE also does this if the PCRE2_UCP flag is set. [13:29:46.0879] TabAtkins: is this the proposal advancing to Stage 2? We need it move to the TC39 org [13:29:48.0218] https://github.com/js-choi/proposal-hack-pipes/ [13:32:52.0247] leobalter: the current plan seems to be to transfer it in and archive it, and repurpose the existing pipeline proposal repo to match the new shape [13:32:57.0286] it's being discussed in the pipeline room [13:33:47.0630] which room? I can't find it on Matrix [13:33:57.0601] is that in another server? [13:35:32.0623] https://matrix.to/#/!mjlgwjKxWUpgSgeCQU:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org it's in the tc39 space [16:11:52.0917] > <@jridgewell:matrix.org> ``` > function* foo() { > yield 1; > return 2; > } > // undefined > it = foo() > // foo {} > it.next() > // {value: 1, done: false} > it.return(3) > // {value: 3, done: true} > ``` a more fun example: ``` function* foo() { console.log('init'); try { yield 0; console.log('try'); } finally { console.log('finally'); yield 1; } } g = foo(); g.next(); // 'init', `{value: 0, done: false}` g.return(42); // 'finally', `{value: 1, done: false}` g.next(); `{value: 42, done: true} ``` [16:12:02.0612] or you could even get labeled blocks involved if you wanted [16:12:18.0558] you could break out of the `finally`, thereby suppressing the `return` entirely [16:12:28.0220] rather than just delaying it, as above