Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Waldemar Horwat | WH | |
| Bradford C. Smith | BSH | |
| Robin Ricard | RRD | Bloomberg |
| Richard Gibson | RGN | OpenJS Foundation |
| Michael Saboff | MLS | Apple |
| Jordan Harband | JHD | Coinbase |
| Philip Chimento | PFC | Igalia S.L. |
| Istvan Sebestyen | IS | Ecma International |
| Nicolò Ribaudo | NRO | Invited Expert |
| Jack Works | JWK | Sujitech |
| J. S. Choi | JSC | Indiana University |
| Surma | SUR |
Presenter: Aki Braun (AKI)
AKI: I am proud of all of you who got up early. Hi. I am Aki. I know it's 10:00 a.m. In London, but I'm in San Diego and I haven't gone to bed yet, so I apologize in advance for… everything. I hope the Europeans in the house are enjoying your moment of the West Coast Americans struggling with really terrible time difference. You deserve schadenfreude. I am a delegate of PayPal and I am co-chair of this august body. I am joined by Brian Terlson from Microsoft and Rob Palmer from Bloomberg, and then we have chair emirati, Yulia Startsev and Myles Borins though he is officially done. This is my second last plenary as well. I will be joining this group of former chairs who can't entirely quit you. I assume by everyone's presence here that you have filled out the sign-in form. It a requirement of ECMA's bylaws that we keep attendance at our meetings. If you haven’t, please do. We need to collect information and the one time I had to do it manually it really sucked a lot. Don't do that to me.
AKI: I want to start this morning by addressing our code of conduct, which is available from the link in the footer on our website. Anyone participating in TC39 activities is expected to be familiar with the expectations outlined in the code of conduct and behave in a manner that reflects a respectful understanding of it. If you have a concern relating to a possible violation, by all means reach out to the code of conduct committee. Next up, we have communication tools. […explains comms tools]
AKI: Okay, and something more pleasant. Kevin, are we blessed by bakkot bot transcribing today?
KG: We are. It's doing pretty well so far. I gotta say it might die, and if I am asleep when it dies, then it will stay dead. Usually I just kick it whenever it dies, but I can't promise I will be awake for this whole meeting. But hopefully it will stay alive. So we have it at least for now.
AKI: For the uninitiated, we take really extensive notes during our meetings. We make sure that we are sort of doing our best to track what everyone says so that we can capture what their intent was. That's kind of our goal, to get people's words on paper in a way that makes their intent clear. The easiest way for us to do that has been actual transcription. Kevin made the amazing bakkot bot, which transcribes into our notes documents. Before that we all did it manually. And if the bot goes down, we will need to do it manually again. If you have not contributed to notes in a while, maybe this is the time to keep an eye on it and be there to either edit the bot or jump in and take over. And if you're new, being an editor on the notes during plenary is a really great way to sort of get all of the words that are being said into your head. Because being new to these meetings can be a lot so I highly recommend trying out note-taking.
AKI: Next meeting is December 14th and 15th from 10:00 to 3:00 Pacific Standard time. I'm calling it Los Angeles. I know it could have been San Francisco. But we always do San Francisco. So we're going to pretend we're in LA next meeting.
Has everybody had an opportunity to review last meeting's minutes? Do we have approval? It sounds like consensus to me, great. Has everyone had the opportunity to review this meeting's agenda? Great, we formally adopt it.
RPR: In 2021, we did a year of eight remote meetings this year. We actually increased the numbers as I'm sure everyone knows because people wanted to meet more often. This year we received negative comments when we had TC39 two months in a row, and I thank people who gave feedback on the reflector. Thank you, everyone who contributed to this spreadsheet with all the various feedback. That was really detailed, and we saw that the majority of people wanted fewer meetings. So that is the big change that we're going to make for the next year. Even though we tried eight meetings this year, for next year we're going to go back to six meetings. So this is the plan ahead. For remote purposes, and so that people are not on online all day long, we're sticking to the four-day structure with a couple of sessions. I will say we did have feedback to say, could this be flexed, maybe one of the sessions to cope with other time zones, and I think that that's definitely on the cards for next year. We haven't actually specify that precisely yet. We're just doing dates for now, but one of the other things we are going to try for 2022, and I'll say "try" because who knows how the world will go, is that we do have some volunteer hosts for real-life meetings just like we used to do. I think a lot of people here have been to some of those real-life meetings, but we used to do six a year, which was a lot. So we're not proposing that. So this is 2, maybe 3, 1 for each continent, real-life meetings starting in June 2022 with a particular opportunity to join up with OpenJS in hosting event. Obviously we're not going to give up what we've learned about remote meetings. So it is essential that any host must offer high-quality - let's call them hybrid meetings, meetings where you have some people in the room with microphones. So if everyone can hear everyone. And also, even though we're saying we're bringing these back, this does not mean that anyone should feel any pressure whatsoever to attend. I'm quite sure there will be some people who are not comfortable, with the way the world is going, attending in real-life or remotely, that's no problem. I'm going to do everything we can to make sure you have a good time remotely. And an obviously we know that people are going to want to know what will the host will be doing with safety measures so we will make sure that comes out.
RPR Yes, so then for the actual times and dates, so we've got these remote meetings. So remote Seattle, remote New York, and then it's June to coincide with OpenJS world. And when we're suggesting that that's the first time we could consider this. We will obviously reconfirm before that time. And then the other real-life meeting that we've got reserved is Tokyo. And so that's a reinstatement of the one we never had two years ago, and then we're still in few discussions to see if we can get a Europe one. We'll see how that goes. For the June one, obviously, because this is a bit special, the first real life meeting in what will end up being over two years. Here's a few more details we've got at the moment. So this is we've been kindly invited by OpenJS to have our event alongside. I think, you know, we've done this kind of thing before where there are conferences going on and they're expecting to have Safety measures and we'll find out more about that. Daniel also highlighted that there's some overlap with the Jewish festival of Shavuot. So we're going to make sure we try and be compliant with that by serving cheesecake. He's told me that this somehow makes it compliant, and I believe it. I want to believe. And then luckily we can, you know, we get a conference with this as well, so it's nice two-way thing. And quite often with these things we have a panel if you wish to step up, but of course, we're miles away with months and months away from this happening, don't book flights yet! Who knows how the world will go, but the key is that we do appreciate real life meetings. I think we're probably not going to go back all real-life. And if anyone has any comments on this, the chair group is eager to hear and so is Jory. Jory is eager to hear what TC39 thinks about this. So we have reflector post for this if you have any feedback there.
Presenter: Istvan Sebestyen (IS)
IS: Yes, really difficult. Okay. Anyways, I'm looking at the watch yet. So I try to be as quick as possible because also the content is very much similar to the ones that you have seen before. So it is really more for reading. Next slides: The list of the relevant TC39 and Ecma GA new documents since the last TC39 meeting. I will just show you. Next slide: status of the TC39 meeting participation. Still very high, 80 remote participants, Next slide: the latest standard download and access statistics. Pretty similar to what we have seen before. So TC39 is definitely the most successful and most searched TC regarding access to the standards and downloading the standards Etc. Next slide: last but not least. So this is new, it is short status of the project to generate from the master HTML version to a good PDF format of the TC39 standards. So, that's new. Next slide: And then the regarding the TC39 GA and Execom meeting, that will be very, very fast because you've already seen it regarding the GA meeting and the execom meeting for next year. Nothing has changed. So it is just a confirmation. So this is what we have on agenda for this presentation.
IS: Now, The latest TC39 document, there is for those who are only watching the GitHub and not accessing the Ecma TC39 file server. That is basically a duplication of what is going on there for archival purposes, so it is not really necessary to go all the documents here. The purpose of that TC39 file server is mainly for long-term archival purposes and for information purposes to the other people who are not TC39 delegates. Now regarding the GA document list and I have actually three slides full with them and this has to do with the fact that I have selected those, which I thought it might be of interest to you. These are mostly related to TC39; like the first found on the trademark registration of ecmascript. So this has been, this has been extended again for 10 years. And also we have done the same thing for the UK, etc. Etc. So here you find you can you can you can find also trademark registration effect registration for the European commission country. So this is the third one Etc.
IS: Okay, then the TC39 meeting participation. So these entries are for the past meetings. So the latest one is for the August 2021 remote meeting, actually quite good. So 80 people, all of them of course remote. Also, the number of the companies they represent is 28, so I think it is quite good. And now regarding the October 2021 meeting we will see how many people will be there in this meeting. And how many companies. But, as always, it is a great turn out and actually this represents in my opinion 60% of all Ecma current activity. So currently in Ecma we have one huge technical committee - and this is TC39 - and then all the rest are significantly smaller.
IS: Okay, regarding downloads, the tendency is very much the same. Again, the total number of the Ecma standards - so you can see it - is ours are about twenty-seven thousand and more than the half. is coming from TC39 in spite of the fact that the current PDF format has not the best quality, i.e. for ECMA-262. By the way ECMA- 402 is OK now, this has been fixed by hand by the Ecma office. So in total, TC39 downloads represent more than the half of all downloads. Now, what is perhaps interesting to see that the JSON standard (ECMA-404) download is going up. So now it - starting from the beginning of the year - more than 10,000. So this is an interesting trend. Also there is a growing interest in the ECMA-402. And the ECMA-414 is this, this is the one that has been fast-track to ISO/JTC1. We did that a few years ago, in order that we don't have to Fast-Track each and every time, every year, the two important technical standard, the 262 and the 402, so you can see its access and download is much less, but from the tendency point of view, it is the same. Next slide: Now here it would not go into details you can just read it. On the left hand side is the access for the HTML versions. So this is the master quality and the access is rather high. And as you can see also already for the 12th edition, which is the 2021 edition. So it is also getting up and up. So this is quite good and here on the right hand side are the download figures, still already 70,000 downloads of the not terribly, Good quality format which is what we currently have. Then here next slide: This is the ECMA-402. So, as I mentioned, it is also going up. So that is a good thing. Also the access much higher than the download on the right hand side, the download. Next slide: Now this is the new message where we are. Now, for the “HTML to PDF good quality conversion project” we didn't get too far so far. There was some exchange of messages between ECMA Geneva office, and some people of the TC39 folk, but as I see it from the outside, no concrete progress yet for the selection of the tool - as far as I know. So parallel to that when I saw I contacted Allen W-B, who is always my very good TC39 historic advisor. Since he was one of the last ones from the editors who has actully produced good quality pdf version, so I asked him what he would suggest now. Allen has proposed that there is a program called PDF reactor. Which is a conversion software tool from a German software company in Saarbrücken and we have already taken contacts with them downloaded the program which is available also for testing. And we discussed with the Ecma office that Patrick Charollais will also try to test it and then if this will work then we could get the software tool for 2,000 Euros for 4 licenses. I think this is a reasonable option. If it works, fine. I have also informed the Ecma Chairs, have sent them the user guide for the program etc. So, according to the user guide it seems to be a good tool. So I hope that something comes out that, but of course, there is no guarantee. So this is the status where we are on that project, according to my knowledge.
IS: Now next slide: this is just a copy of the Robs Reschedule slide for 2021. Actually, we are now in the long run. So this is nothing new. Rob already mentioned the main points. So my additional point, which is my personal opinion, that “local only” meetings of the good old times will likely not come back. For different reasons, companies will be less “travel friendly” but more “working at home”, Etc. So what I am expect that such “local only” meetings that we have had will also not come back. However, the “remote only” meetings that we are exercising now for two years l think we very happy with their quality. The tools are good. In my opinion, we can hear each other well - also for the audio point of view. We can make good progress with the current conferencing tools. So this will in my opinion stay. And actually the question is what about the so-called “mixed meetings”, i.e. we have “local” and also “remote participation”? In my opinion before we start with the first meeting next summer we should do a little bit of tool testing, like we also did in the past. Just as a note, three years ago when we were forced to try to bring in remote contributions because some people could not come and present their stuff in person so that worked well too. But for a remote participant to follow the “in person part” of actual meeting was difficult. Always the audio part is rather poor. Sometimes you hear it, Sometimes not. Or you here only one person, but not an other. So I think we have to test that, so that we have equal quality with what we have today with our “remote only” meetings. And the same thing is also sometimes - but less frequently than with audio - also with different presentations of the associated slides. So my point is that the “mixed meetings” can not be worse than the current “remote meetings”.
IS: Now regarding the GA venues and dates. It is exactly the same. The only change is now apparently the meeting here in the December meeting 2021. It is now in the Ecma office. It is planned to be a mixed meeting in the sense that if somebody wants to go - in spite of the outgoing Corona in Geneva - then you can take that challenge. You can go to the meeting, but you have to tell the Ecma office that you want to participate. Because if too many people are taking the challenge, then they have to go to hotel with a larger meeting room, right. Etc. So it will be in Geneva. And this is for the December meeting. For the June meeting it is still the same, but it used to be so Switzerland, but all the details are to be determined, whether it is a face-to-face meeting or not or whatever. The same also for the December meeting. The date is absolutely the same. Now regarding the execom meeting, the Time for the execom meetings, which also review the technical committee work and these meetings the TC chairs are strongly encouraged and invited to participate and And also ask the answer, the question, question, etc. Etc. are completely unchanged. There are also other execom meetings. So which are not involving TC work. Very often they are set up rather on an ad-hoc basis. So we don't know anything about them. Maybe they will happen. Maybe not.
IS: And this is the end of the presentation. And so thank you very much for your attention and if you have any question, please ask me now or write me an email and more than happy I will answer them. Or do it over to GitHub if everybody should be informed about the content. So thank you very much. So that's the end.
Presenter: Keving Gibbons (KG)
KG: There have not been a lot of major editorial changes since the last meeting. We're starting to use these structured headers, these machine readable headers in little DSL in more places. We marked with as legacy per consensus at the last meeting. One thing I wanted to call out is that all the old editions of the specification, which had been hosted on the GitHub for a while and disappeared after a year are now back and should be back permanently. So those old links should be fixed if you happen to run into those.
KG: Several normative changes. Running through them very quickly. They're just things that got consensus last couple meetings. We made octal literals normative. Object hasOwn and class static blocks were at stage four and have been landed. And then these last two are things that the editors did where we assumed that the intent was clear that the current specification was incorrect. So, 2523 is, strictly speaking the math methods just just said that they returned an implementation defined value and didn't specify that it had to be a Number. We changed that to be a Number on the assumption that was what the committee had intended. And then 2505, we discovered that the ContainsArgument sdo which is used to give an early error when you refer to the arguments binding in a class field, that isn't supposed to descend into nested functions, had omitted the async generator cases, so that it did descend into async generators, which meant that it was strictly speaking an early error to refer to arguments in an async generator in a class field, which was kind of silly and it's not what anyone except engine 262 did. So we changed that on the assumption that that was always the committee's intent. But if anyone objects to these two normative changes the editors made on our own, please speak now. And then some other really tiny stuff I'm not gonna to get into.
KG: There's a bunch of upcoming work, all of the editors are actually working on different projects right now. So I am working on an auto formatter that will just be pedantic about the white space and stuff but instead of just complaining about it, it will fix it. Hopefully that will be ready soon. MF is working on completion record reform. So, this is a thing that we have been wanting to do forever and are finally in a good place to approach it where the spec said that every algorithm returned a completion record, which is basically like the results type from Rust, for example, if you're familiar with that. It represents either the value or a change in control flow such as an exception. A lot of abstract operations, it didn't really make sense for them to do that. They were operations that inherently could not throw. In many cases they were even static operations. But those are still supposed to return a completion record. It was Implicitly wrapped and then implicitly unwrapped. That sort of implicitness is often very confusing. So we're getting rid of that implicitness and making every operation be precise about whether or not it can return an abrupt completion, which is to say, whether or not it can return a completion record or if it just returns a regular value. So that won't actually have that many changes to how to read the spec. But it will affect a few places and get rid of some of the implicitness which confuses people. Otherwise, it's mostly the same except Shu has been working on a ‘can call user code’ annotation, which we'll get to on the next slide.
SYG: Yeah, I can talk about this real quick. So it's not quite ready yet, but I wanted to take this opportunity to kind of call out that we have a preview build available. So the other implementers in the room especially, if you could just browse around and give your feedback there, that would be greatly appreciated. The whole point is that there are these abstract operation calls and some of them can end up causing user code to be called by things like proxy traps or tostring. And there is a mode now that you can toggle and it will pop up this little uc annotation on those abstract operation costs that can call user code. The styling of that might change, but the screen shows what it kind of looks like right now except without oval outline. That's just to highlight what it looks like. If you want to take a look, it's at number 2548, and you scroll down to the bottom. There's this preview link click on details that will load the preview build. It's not quite ready yet because there's some false positives and there's some false negatives. And if you notice anything that is missing or is needlessly conservative where it says, it can call user code, but in fact cannot because it's for example, calling like Tostring with something that, you know, cannot trigger a user defined tostring. Please comment in the PR. Thanks.
KG: And then the last thing - we are planning to rename the default branch from master to main. This will happen on the last day of the meeting. So, if you have any open PRs, they will automatically get updated but your local copy, you will need to manually tell it that the branch you are working with now is main. This follows Test262, which did this a long time ago. It didn't seem to break anything. Ecmarkup did this a while ago, it didn't break anything. So just as a heads up, that will be happening in a few days. And that's it.
AKI: Thank you. There is one question on the queue from Mark Miller.
MM: Yeah, the acronym SDO went by. Could you explain what that is? And also, I just also wanted to say Bravo on the user code marking, that is awesome to have to be able to see that marked up.
KG: SDOs are the syntax-defined operations. These are just the operations that are defined piecewise over the parse tree rather than just by having a single algorithm - so it's just a particular style of algorithm in the spec. So for example, Evaluation is an SDO because Evaluation is defined piecewise over a bunch of different productions.
MM: Thank you.
AKI: Also, SDO stands for standards development organizations internationally.
YSV: I just wanted to say basically what Mark said. The user code to annotation is awesome. Thank you so much for doing that. I'm looking forward to reviewing it and seeing how much it improves my reading of the specification.
Presenter: Ujjwal Sharma (USA)
AKI: Ecma 402!
USA: So, hello, if you don't know me, I'm Ujjwal and welcome to TC39 in the UK. What is a coma for two for the uninitiated Ecma? 2402, includes the built-in internationalisation? Library. So you can do cool stuff. Like daytime formatting for one. How is it developed? It is a separate specification. So we just talked about Ecma 262. This is all in a separate specification and it's developed by TC39 TG2. So technically a subgroup of this body. Proposals move through their regular stage at you as you would see in the few items. He's in the next three days. We're so you'd see a bunch of proposals the specific this specification. So we're all looking forward to that, We have monthly to our phone calls to discuss the finer details. We get into a little bit more detail at these than how we then the level we do in these calls. So feel free to join those. yeah, feel free to reach out to us if you want to join and more information on the Repository. So, getting to the the media beds, what are the normative pull request? have one which adds a new numbering system. So this numbering system is called TNS a it's per request 6061 for it. Adds a new entry. so essentially, if you have not seen this spec yet. There is a literal table of all the supported numbering systems. we are trying to I add another one to this. Now. This new numbering system is actually a fresh addition, in Unicode 14. The only problem with that is that it's not yet shipping in stabilize you, I see you being one of the popular implementations that are number of implementations. Sorry, implementations of this Unicode Locale data that a number. JavaScript implementation is actually build on top of. So right now, this will request is delayed for merging at least until November. So, maybe you'll see it in the December meeting, or maybe you'll see later. But yeah, it's one of the new pull requests. Another one which is up for discussion at this meeting is to use list format for array.prototype toLocaleString. There's there's really not much to say about this. So this is pretty much exactly what the title says, then when you call array.prototype toLocaleString right now. does something quite bespoke and we realized okay. We already have list format. So why not just use that? So yeah, this is something that we will be asking for consent at this time. So, first of all, do we have consensus for this? Do people have any thoughts regarding that?
KG: Can you explain more what changes this implies?
USA Yes, so I can literally open up the pull request. So in the body of Array.prototype.toLocaleString we do some string operations manually, which is quite look l. So, I mean, it is kind of look out sensitive. It says, which is appropriate for the hosting environments, current Locale, but this seemed wrong on two, two points. First of all, it's a little bit awkward that something in, you know, it is not using a formatter like, you know dates used for a matters, but you know arrays don't use built-in for matters now that we have a formatter it's better to use it And also there's there's much more functionality in list format. So you directly get access to all that. That's that's basically the motivation for this.
KG: So, just looking at this PR, it's hard for me to tell what the normative change amounts to. Like, is any existing code going to start behaving differently, and if so, how?
USA: The idea is that, you know, the result that is returned by the to look out string, sort of Locale sensitive functions is not something that people would depend on because it's completely dependent on what the users Locale is and what the Locale data is and so on. So while this might incur some change in what the result is in certain implementations that doesn't have to No, be that doesn't have to be a web compatibility issue, per Se. Another thing is that, I believe a number of implementations are using. We do know, the same native functionality to do both of these anyway, so it would be nice to sort of formally unify that.
KG: That sounds reasonable. Just looking at this first line on the right-hand side. It's constructing the list format constructor. Is that like potentially going to be doing any validation of options that wasn't being done before and causing code to throw that wasn't throwing before?
SYG: I.e. why is that a question mark instead of bang for construct?
USA: I don't know if this can throw I can check but you have not. Maybe is Frank on the call? May be frank and explain better. Maybe not. It's probably a bit early for Pacific time. So, yeah, maybe we can revisit this. Let's then come back to this later and not record consensus on this for now. Okay, so that's the only thing that I wanted to ask for consensus on. I just to give a little bit more overview in a bed for two only if the time permits those. So do we have time on the time box, though?
AKI: The time box is tight, we're over.
USA: So let's skip that but the thing to look out for is segmenters going for stage 4 so hopefully that'll happen. If you want to get involved please reach out to us, and thank you.
Presenter: Chip Morningstar (CM)
AKI: Next up, We have 404.
CM: JSON abides.
AKI: Great, great.
Presenter: Yulia Startsev (YSV)
AKI: Next up, Yulia with ECMA recognition Awards.
YSV: Ecma nominations. This happens twice a year. Here's a quick refresher. The Ecma awards are given twice a year, June and December. We are coming onto the December nomination. There are two kinds of awards that are given they are awarded for dedication and support of Ecma standardization. The more common one is the Ecma recognition award for a service to the TC or tip Ecma. for example, an editor of a Torture. Ecma fellow is a Lifetime Achievement Award, which is pretty rare. And this year. We're only going to be well also. Last year, we only recommended recognition Awards, and we're doing the same this year. Again, procedure is the following: someone in TC39 proposes a candidate with a rationale, then TC39, that's you all, supports and accepts the candidature, the TC39 chair communicates, the candidature to the Ecma GA. And finally, the Ecma GA in December will accept or reject the candidature and grants the expected Ecma Awards. So the first nominee is, of course, Aki because she is stepping down as chair and it is our custom to award our chairs and editors as they step down with an Ecma recognition award to highlight the work and dedication that they've done to help the TC. Run. Aki is a PayPal delegate. She's been co-chair. She's been doing this job for three years. (I will correct the slide.) And she is stepping down this year. She established the onboarding process of our delegates, which many of you have been through. She automated much of our process. She has done all of our timing and agendas planning, which is a lot of work, especially with all the restrictions we have. She maintained the IRC permissions while we used IRC and later on she helped Marshall in Matrix after it first prototypes. And by our I believe it was our inclusion group. She's highly responsible to new delegates, internally, a great Steward for administrative tasks, and she's set a fantastic example on how to collaborate effectively and how to get through contentious issues. So, I strongly recommend that we nominate Aki. Anyone objected?
KG/IS/RPR/etc: Seconded.
[AKI weeps gratefully in the corner]
YSV: Yeah. Okay. and next up. Jinkx is another strong candidate. I propose we re-nominate Andre Bargaull (@anba). We have clarified his situation as a delegate of Mozilla. So he is now officially a representative of Mozilla. He has extensively contributed to the correctness of and development of the specification. I think the specification is of a significantly higher quality due to his contributions. He's a top contributor to Ecma 402 by the number of commits. He's a second contributor to Ecma 262 and he is a contributor to test 262, the amount of work that he has done, cannot be understated. He has also done many all around reviews. He also participates as part of Mozilla's review process and has been absolutely instrumental in our implementation. He's been doing this for a span of over six years. I also very strongly recommend that we recognize his contribution and the impact that he's had on the specification on and on TC39 as a whole. Any thoughts here, any objections?
IS: Seconded.
AKI: I third.
YSV: Okay, that's it. Is there any? So I have this slide but I would like to note that we cannot like Ecma wide only two to three awards are given per award cycle. So we are recommending two. So if we recommend a third, we need to think hard about other candidates. I think I've shown a priority in the candidates in this slide deck. We can carry over to the next GA if necessary. Another point to which we brought up in a previous meeting is, do we want to create a award? I think, yes. I have not done any work on this but this is something that we can certainly think about whether or not it should be a physical award or if it should be a letter. I think it's nicer to have to have something physical. And yeah, that's it. Are there any comments, any questions? [nope] And that's it for me. And I suggest we go forward with these two candidates.
USA: I didn't want to say it out loud, but it's just I wanted register support for the TC39 specific award. I think we give it the two candidates we have right now the bars too high. And I think the amount of awesome work that goes on this committee. We should recognize people much more.
YSV: I agree. This is a very high bar and I think it would be nice to recognize - we have a lot of fantastic contributors who have been doing a lot of work that's been unrecognized. Andre is the first that we're recognizing and it's a special case because he is an official Delegate for Mozilla for others. It will be more difficult. And I would like to see a way that we can properly recognize them. So, Ujjwal, since you said that, how about you work on it with me to figure it out?
USA: Sure, I'd be happy to help.
YSV: Okay, super, because I need someone to also help me figure out how we're going to do this.
AKI: All right. I look forward to seeing what y'all come up with.
Presenter: Shu-yu Guo (SYG)
SYG: So this is a normative change. I am asking to make to the resizable buffers proposal from me. So I didn't make slides for this. I think it's best to walk through this example to see where the corner case comes up. It is a corner case that we discovered during implementation. So to set the stage, there's a bunch of Array methods and TypedArray methods that basically behave like where they - they read some length of the source array and then they do some operation by looping over the source array. These are methods like slice copyWithin, fill, slice, ec. So slice, for example, reads the length of the source array, and depending on how you want. Want to slice that into a different array, basically, you know, copies the portion that you want to slice into a new array. There's nothing new there. That's just what those methods do currently. With resizable buffers, those methods still have a defined Behavior, but there is a weird Corner case that comes up, which I will try to explain. So walk you all through this example here. So what this example is doing is the first we're creating a sizable buffer. That's all this hose. And we're creating a float64. So a double view on that buffer. And then we just fill it with some initial values. This doesn't really matter. And then we're going to do something tricky. We're going to make a new TypedArray subclass whose sole purpose is to be very tricky when you do construction by making the Symbol.species getter such that resizes, the source buffer. Is this clear so far? This subclass does nothing else except being tricky when you try to construct a subclass by resizing the buffer during the middle of some operation. If that is clear so far, moving on. What happens in this case is that - say we create a new subclass of this array. The intention here is that I create this subclass of this array. And then I call slice on it. And the idea is that during the call of slice, my intention for this example is that during the call of the slice, is when the source array gets resized during the middle. So what happens is that at the beginning of the call to slice the source buffer is not yet resized, and then in the middle of the call to slice, it is resized because it's creating the subclass instance via looking up Species. So, we now have a situation where the latter half of these methods like fill and slice and copy within our reading from a smaller buffer than what a thought. We thought the length of the buffer was at the beginning of the method. This is fine in that. We have to find to behavior for what this should do. For example, in arrays, You could do this somewhere. Thing in a raised without reciting, right? If this were a regular arrays and not a typed array, this line would be something like, you know, the source array,.length, equals whatever want to resize it to you. Where the corner case comes up is that the current spec behavior is basically, we Loop over the original length that we read. So, the original length is in this case is 4 and then we are changing it to 2 so. So something like, slice will still Loop over four elements and copy those four elements except for elements index 2. And index 3. It will be reading basically undefined. That is fine for arrays, you get undefined. For resizing array buffers on which we are reading floats, undefined coerces to NaN. So if we go with the existing behavior for maximal, consistency, with typed array methods the now out of bounds indices become NaN, which is arguably pretty weird. Whereas I am proposing in this PR. This is PR 75 that we just stop iterating for the typed array methods. When the backing is a resizable buffer. So that in this case you just don't get it right into the you just don't get a rate into the out of bounds areas and then you don't assign, you know, you don't do this out of bounds assignment where you to balance. And in this case, the, the newly-created. Typed array by slice. You don't really assign to it. So they remain 0 and this might be more expected. in any case, this is pretty corner case-y because, you know, just don't resize your buffers in the middle of an operation. You can do that via hooks like this, but that's generally a code smell and really bad practice. Okay, so this is still don't do that, but we do need to spec something and arguably the existing behavior is super confusing and it is more implementation complexity in that you actually have to read out of bounds, you know, it's out of bounds and then you do this NaN conversion thing. so, what I am asking for consensus here today is adopting the behavior where we do not read things that we know to be out of bounds in the slice method, copyWithin method and in the fill method for source arrays that are backed by resizable array buffers. This might have been confusing. Are there questions?
MM: So, how would you specify - how would the specification of the algorithms change so that they don't have this problem and would this change in how the algorithms are specified? observable in, in terms of what proxy traps they cause
SYG: I will double check on the, so I don't know if this is the most up to date version of the PR, but basically how the actual spec change had to spec changes is let find an example for the clearest. I don't think any of these very clear from just reading this example, but the basic idea is that at some point, you have to reread the length. Anyway, like the the methods already do And after you reread the length, you have to final length. and there will be some check like this where if you are, in fact out of bounds now just do nothing. And as for does it change the observability of proxy traps? My intention is we would only do this for methods Methods acting on typed arrays, back my resizable buffers, which doesn't exist now, so I'm not sure if the question is this applicable? There is no, I'm not asking so
KG: It definitely doesn't change any proxy traps, because these methods aren't ever going to calling any proxy traps because they require their this to be an actual typed array not a proxy for one or anything.
MM: I see.
SYG: I thought I was also changing the array methods, but I am not. So yeah, so absolutely right now.
MM: Okay, Okay, good. Good. That settles that.
WH: Do all the methods read starting from the beginning towards the end or are there any which iterate backwards?
SYG: The message, copy with infill slice, all iterate from beginning to the end.
WH: So what is this direction = 1 or -1 on the slide you’re currently presenting?
SYG: oh, this is this is copy within. I don't quite remember. This was like while ago. See. it might actually read it from the back, if and in any case, I think your question is, how does it like reload the length each time through the loop. Is that your actual question?
WH: If you have something which is backwards, then you will not fill in the lower values if you abort the loop.
SYG: This doesn't abort the loop. This basically indents, the body of the loop where, if it's, if the element you're trying to do is out of bounds, do nothing. Just continue to the next iteration. iteration. And otherwise do the thing.
WH: If they skip an iteration, what else do they skip in that iteration?
SYG: all of these operations are not are are like, it's assignment. It's all of these operations is read something from the source array at index assign it to Target array at an index. There is no user, defined predicate or anything like that.
WH: Is the value that used to be in the target area always zero?
SYG: It's always undefined, which is the problem. If it were zero would be fine because it's undefined for integral typed arrays, that coerce, to floating Point type. There is like a coerce to NaN which is the surprising Behavior.
WH: No, I'm asking, if you skip your assignment, what is the value that would have been overwritten but isn’t? Is that always zero?
SYG: Yes. Because it's always on a newly created typed array initialized to zero. So that the Crux of the changes is, Before change. you can see some NaNs, after the change all you see are zeros.
WH: OK. Regarding the NaNs, I don't really care.
SYG: I can Next up on the queue you in. so,
YSV: I just wanted to give what our review was of this. We do think that the zero makes a lot more sense than the not a number outcome. So the general direction of this proposal of PR 75 We support although we haven't started our implementation on resizable array buffers. So we'll probably have more comments in the future.
SYG: Sounds good.The queue is now empty. I am once again asking for consensus on pr 75 Behavior, which is Zero's not NaN's caused by reading known out of bounds indices in a source array.
MM: I like this.
AKI: We have consensus.
Consensus for PR 75.
Presenter: Ricard Gibson (RGN)
RGN: All right. Thanks everyone. It's been a long road to get here and I'm excited that we're approaching its conclusion. So background, as usual on Segmenter, is that it augments the existing code unit and code point segmentation that already exists with Locale-sensitive grapheme and word and sentence segmentation so that you can work with text at a higher level, and because it is Locale-specific if it exists in Intl rather than on ECMA-262 strings. We've been shipping in V8 and JSC for a while now, and there have been a few changes since the last update. A couple of them in response to implementer feedback, and the rest some editorial tweaks for consistency with the ECMA-402. TG2 approved it last month for Stage 4, and I am coming now before the full plenary meeting to ask the same. We have no open issues that are relevant for V1, although a V2 follow-up is expected at some point. And we have an ECMA-402 pull request and MDN updates that are probably going to land this week. We didn't quite get them merged in time for the meeting. But all told everything is in good shape. This first reached stage 3 four years ago, was demoted to stage 2 two years ago, and has worked its way back up since then. So, a relatively short presentation on this. And I'm ready for the queue.
AKI: Okay, but before we go to the queue, can I ask one question? Do you know which meeting it was introduced in?
RGN: Oh, no, that was even farther back than I looked. So I don't know.
YSV: So, we had initially requested that this gets delayed in advancement because we wanted to complete our implementation on top of ICU4X. It is currently not finished. However, we are comfortable with allowing us to move to stage 4. We're hoping to get that done early in the new year and then we should have two valid implementations on, different ICU implementations based on different ICU implementations.
RGN: Yes, absolutely. Thank you for raising that. I meant to include in the slides and I guess I missed.
AKI: That's the whole queue.
RGN: All right, great. It's nice to come in under the time box. Yeah, so I would like to ask for stage four or objections thereto.
AKI: That sounds like consensus to me.
RGN: I'll take it. Thanks everyone. Thank you. And strong support from Ujjwal. Got on the queue just in time.
- Stage 4
Presenter: Shu-yu Guo (SYG)
SYG: So this should be a fairly short thing that really lot of technical content, but you all know structure clone. It is this thing, is this algorithm that's defined by these paired - technically I guess they're not abstract operations because they're defined in HTML, but conceptually abstract operations called structure serialize & structured deserialize. And it's defined in HTML for the purposes of cloning values, including JS values. So this is defined in HTML but it's not just for HTML, it's for web APIs as well. Also for JS, things like objects and maps and sets, its most notably used you interact with this algorithm when you transfer stuff or clone stuff, cross workers with post message, including node. And it's also now directly usable on the web with the structured clone function on globals. so, the problem is that this has a maintenance burden and we've actually seen this play out a few times recently where we added a new thing like AggregateError and then we forget to do the layering part where we need to extend the structured cone algorithm on the HTML side to support the new thing we added, and it's not like an implementation issue, people usually catch this and then the implementers who actually implemented it, but we were leaving the specs in a bad state because there's some It's not that complete, inspection until someone notices and says, hey shouldn't we add this to structure clone? And then someone makes a PR so on and so on. So maintenance burden is the main issue. The proposal here, let's pull structure clone algorithm into ECMA-262. Will Define this pair in 262 with a new name. I suppose, the hosts like HTML will use these algorithms for the court JS values. values. They will continue to define whatever steps that need for the, you know, HTML values that are not 262 stuff. We should own those algorithms, The one point of technical discussion here. Is that HTML already has spec'd - not just spec'd, it's shipping everywhere - it's incompatible to change the types of errors that are thrown when the algorithm throws an error currently. They throw their own exceptions. So, we're not going to, we're not going to pull DOMExceptions in 262. Nor are we proposing to change the kind of Errors being thrown here. This is purely a layering / editorial change I am proposing. And to that when we pull these, these core algorithms for the court JS values in 2262. The idea is to make the errors host to find to be as to what kind of errors are thrown will just say something like throwing error or sorry. Go through a whole to find error. And just from a layering perspective, these are algorithms for core language values. TC39 feels like the right layer. And yeah, like I said, the proposal is strictly editorial about layering. There's really no political fight here, the HTML editors themselves approached us to do this. They feel that maintenance burden as well because they have incorrect or incomplete, spec until somebody notices. It's also not an invitation to take this as an opportunity to make any normative changes for how structure clone works. How structure clone works? Is depended upon on the web platform and on node, and this is I don't think it's really open to change. You can make proposals later if you feel really strongly about it, but this is not that proposal. This is just editorial. Anything in the queue before I ask for consensus?
MM: So first of all, I support this. I think that having this under TC39 is definitely the right thing. Also understand this is exploratory. So we don't have to settle the issue that I'm about to bring up - rights as Waldemar just said, consensus on what, you're not asking for a stage yet. But the the issue I want to bring is that we can bring it into TC39 so that we're doing the maintenance on it and the co maintenance on it with Ecma, 262 without bringing it into Ecma 262 and without necessarily making it part of the language. It could, for example, have the kind status that internationalisation has, I'm not saying that we should, but I'm just pointing out that we might. And I certainly have not thought about or examined its suitability for being part of the language.
SYG: I'll respond to that real quick. So I am not proposing - so it depends on what you mean by adding it to the language. These abstract operations I'm proposing to add are not exposed to the language in any way. They are just abstract operations that are designed to be called by a host, like HTML. So normatively, there's nothing changed here. It is not exposed to any users of JavaScript, except if the host chooses to expose it like HTML already does.
MM: So that helps but it doesn't resolve it. It still depends on what the semantics of those Those two host exposed operations are exposing operations to the host, is a boundary between the language and the host expanding that boundary is something that we need to think about. not saying I'm opposed. I'm just saying that I don't know that it belongs in the language and we could do the co maintenance on it without necessarily making it part of the language.
SYG: The benefit of the maintenance is that it's in the same document as 262. Co-maintenance is I guess the de facto thing that is today, and things slip through the cracks.
MM: Maintenance between TC39 and w3c is different than Co maintenance between TG X and TG Y within TC39.
SYG: Oh, I see, co maintenance
MM: I'm not proposing anything, just saying that it could come into TC39 in the same way that internationalization. Does. There could be a TG4 that is specifically about these operations. and I'm just mentioning that in case there is a need not to bring it into the language per se, but we still wanted under TC39 but I'm already convinced. We do want it under TC39, so it can be properly co maintained with the language spec.
SYG: I see. Yeah, I preferred that it remain not as a separate TG. But I'm open to having that discussion. My reasoning is this is not really a big enough area. I think that warrants a TG. Most of the extensions to the marshaling and de marshaling algorithms. when we add a new kind of object, like aggregate error are pretty rote and mechanical. And this really, I don't think there's much design that goes into it.
MM: There might not be much design that goes into the new ones, but it involves taking all the old ones and writing them down in a TC39 document. And if the documents that they're written down into is Ecma 262, then all of those existing serialization behaviors become part of the language. Not observable to user code, but part of the semantics of the interaction of the language in the house. And once again, my preference, my preference is the same as yours if there's not a problem. I just haven't looked at it in order to understand whether there would be a problem.
SYG: I see. Okay, and last response before I think we can go on with the queue, the current algorithms are fully specified in HTML and are written in the kind of imperative fashion that 262 is already written in. So if you are interested, you could read it today and see if you find issues today with what the behavior is. And my contention is that because of the wide dependence on this Behavior on the web platform and in node, it is a de facto JS standard already and we should own up to that fact.
MM: it's a facto standard for multiple hosts, it's not necessarily a de facto JS standard, for example, I don't believe it exists on XS.
SYG: Okay. Next up is WH.
WH: My question is, you asked for consensus, but you didn't say what exactly you're asking for consensus on.
SYG: Here's the concrete proposal that we pull the spec text in HTML that defines what the serialization and deserialization ought to do for values defined in 262 into 262. To make this pair of abstract operations in the spec and refactor, the HTML spec to call these new abstract operations for the core JS values. And make errors, host defined. When we pulled the spec text into the into 262 because currently the HTML spec text directly says something like throws DOM exception. We can't have that. So the only change when we refactored the HTML spec out the steps into 262 is to make the are supposed to find. That is the concrete. Proposal for what? I'm arguing to be an editorial change. I'm asking for more consensus to bring that into Ecma 262, the document.
WH: Are these user-callable things? What are these things?
SYG: They are the algorithms to marshall and unmarshall objects. Which are exposed via post message, I am not sure how postmessage works in node exactly. But I believe it's also called postmessage, which is used to post messages across workers. And when you put When you, when you want to. Post an object across workers, it needs to marshall one side, and unmarshal, on the other side. And the algorithm to do that is, are these algorithms. It is also directly callable on the web by a structureclone.
WH: I’m trying to figure out how they would be exposed in the spec. Would the algorithms only be callable by the hosts or is there going to be a way to call these things from within ECMAScript itself?
SYG: They're abstract operations, like any other abstract operations and there is nothing user exposed in 262, that will directly call them. But HTML will invoke them.
WH: Okay, so it is possible to make a conforming implementation of ECMAScript which doesn't actually have those?
SYG: If your embedder, such as XS, does not ever call those AOs, correct. It would be conforming.
WH: I'm also trying to understand the tension between two things here. One is, you're saying that we would not be making any changes to the specification of these and the other thing is that these would be worked into the ECMAScript spec. Those two conflict to some degree.
SYG: Sorry, what is in conflict?
WH: Anytime you rephrase things, it's an invitation to introduce inadvertent errors.
SYG: So, I'm not proposing to rephrase things. I believe the spec steps written in HTML can be directly copy pasted, except with this DOM exception change. That is the only thing. Because they're already written in Ecma-ese basically. And if that is false, because when we actually come to do this work and we find out that the HTML spec is not suitable for exact copy pasting and we do need to reinterpret then if the intention is not clear and there are things that come up, then we would need to come back committee.
WH: Okay. Thank you.
LEO: I support this as like, when we saw this in HTML. It was something we liked. And I am interested in bringing these obstructions. I know the cost is actually we just set as they are, As you mentioned, like they're ready to try and they have like that the fine grade details in they reflect implementation. I wonder - there is more than one question. I wonder. if you if it is there any desire to have anything generic or low level to expose these abstractions in ecmascript?
SYG: You mean is there a proposal to expose these algorithms in 262?
LEO: Do you foresee being these abstractions being reused in ecmascript as like for structured cloning anything? If this is not part of your plans, that's okay.
SYG: Now, it's not part of this proposal. This is purely for me. I don't personally have any plans to Introduce proposals in the marshalling space.
LEO: So, the other question is, is this abstraction going to be fully reused by node. Is that like there is a use case in know, but it is possible for node to just reuse this abstraction?
SYG: Node does not have a spec. This is a spec thing. They have an implementation which I have in all of these (?) cells. And if they keep with that implementation, they will directly use this algorithm.
JWK: I have a proposal for exposing the structure clone to the language and If we can have this refactoring we will have much easier to integrate, if anyone have interest to know the details, please contact me on the Matrix.
LEO: Thank you, just for clarification. This is more like you out of interest but I believe these should be orthogonal. I support these abstractions being exposed in ecmascript but that Should not block what Shu is proposing here.
YSV: I support the idea of moving this into TC39. That is specifically the abstract operations, which are currently only exposed to the hosts. There may be room for discussion about other APIs that exist in our shared by multiple hosts of JavaScript, but that's something that I think we can talk about at a later point for now, Ecma 216 seems like an appropriate home to get this work finished. And then if we find that we have a number of similar situations that I think that at that point, it would be appropriate to talk about. Do we want to? For example, have it may be an appendix C or maybe a separate document, that will be a home for things that are accessed only by a host or are defined within the specification.
SHU: there is an appendix currently of host hooks, but it's just like a simple list of things that are defined elsewhere. We could flesh that out to be more useful. I like that suggestion.
LEO: Just something that Mark has mentioned like, this might not be used in other hosts like XS, but I think there is value in actually having this abstraction in ecmascript, but it's also like if we are just bringing the abstraction they remain optional for usage in different hosts. Like if you don't use the obstruction, there is not nothing to expose. You simply don't Implement that so I don't think that would be a problem.
MM: Just to make sure I'm not misunderstood. That's my preference as well. My preference. Is that it go in Ecma 262 and become part of the language, but I'm not agreeing to that until I actually look at the algorithms and think about it in the context of the language. So I just want to keep on the table that there is another way to bring this into TC39 without promoting it in to the language if we need to do that.
LEO: Okay. Thank you.
SYG: If the queue is empty, MM it sounds like we don't have consensus then because the path that you want to explore is contra to this concrete path, which is not exploring another way, but like I said, copy pasting it into 262.
MM: I believe we have consensus on somehow bringing it under TC39. But you're correct until I look at the algorithms and think about it in the context of the language. We don't have consensus yet on how to bring it under TC39. And as I said, my preference is the same as your preference. I just need to look before I can agree to that.
SYG: Okay. So we have consensus on the direction. We don't have consensus on the concrete next steps I'm proposing. And can I count on you, Mark, for a timely review of the algorithms?
MM: Yes. Well, how big are they? I just have not looked at all at the HTML spec with regard to this. How much reviewing is this?
SYG: I am loading it.
MM: Just a loose ball park.
KG: It's like 30 steps each of which is like a different kind of thing that can be cloned and each thing that's being cloned is like a couple of steps. It's like, you know, get the [[MapData]] slot out of a Map, that sort of thing. It's a bunch of different cases each of which is quite small.
MM: You can count on me reviewing this in a timely manner.
SYG: Okay, I'll coordinate with you offline. I guess we'll open an issue and then we can coordinate from there.
consensus for TC39 adopting it but not necessarily putting it in 262 MM to review the algorithm discussion to continue in tc39/ecma262#2555
Presenter: Jordan Harband (JHD)
JHD: Morning everyone. This PR was made to the spec, which basically points out that the spec is a little unclear about what happens if you have a negative year zero in a parsed date. The ESHost results of current engines are that ChakraCore and engine262 and v8 will not allow it and will present an invalid Date NaN, and that GraalJS, JavaScriptCore Moddable, QuickJS, SpiderMonkey all do allow it and treat it the same, I believe, as a positive zero, although that last part I'm guessing on but they allow it for something. There was a comment a number of hours ago from RGN on the PR that the preference would be to not allow it. The current PR does allow it though. Either direction would be a great outcome because then we have eliminated implementations having two versions. Which we allow affects which browsers would have to change and there may be comments as that there may be actually ideological reasons to prefer one option over the other. So hopefully it's people either have no thoughts at all or have thoughts about which one they prefer and we can end up settling on one. The goal is that this is a quick agenda item.
SYG: Sure, my preference here is to just leave it, given that I thought the general direction we're going is that we're focusing our attention, efforts, and energy, on Temporal. Given that Date is known to diverge among implementations and there's still these corners that somebody at Mozilla, I think, was trying to enumerate years ago. Well, given the existence of just how big the divergence is already, and Temporal exists, should we have people spending time here at all? I would prefer no.
JHD: Just to clarify, this PR was prompted because of some discussion in the Temporal proposal where ABL asked, is negative zero a valid extended year, pointing out the difference in web reality. So you're correct that we don't necessarily need to change anything for Date to resolve it in Temporal, but we do need to make a decision.
SYG: I see the potential normative implications for Temporal as well. I missed them. In that case, I'll cast my vote as 'disallowed, but not really informed, and seems nice.'
YSV: I can mention what our thoughts are. It actually kind of agrees with what SYG said, but in a slightly different direction. We're not sure it makes sense to fix this for Date.parse() because it's more of a Band-Aid solution for a number of the issues that Date.parse() has, we want to see something a bit more holistic. In addition, it seems like this number, if you divide it by the tropical year length, you will actually get 1970, so that is the positive number story. So it is actually kind of a sensible number that you're ending up with there, it's just negative. We're not exactly opposed to changing our implementation, but we don't really see any specific issue with what it does now in our current implementation.
JHD: RGN, can you provide a persuasive argument beyond your comment?
RGN: The current spec actually already disallows it by my reading, but it's not as clear as it could be. But I think changing this to allow negative zero as a year explicitly would probably be a mistake. Although it would be far from the biggest mistake in Date. And the reason for that is that ISO 8601 also does not support it. So it would be weird — it would be adding to the collection of strange things where ECMAScript goes beyond the standards that it claims to sit on top of. But, that said, there is an intuitive understanding of the year negative zero. So if we decide to require supporting it, it's not like there is substantial harm. It's just adding to the collection of deviations.
JHD: My interpretation of RGN's argument here is that it makes sense to disallow it, which is not what this PR currently does, but what it could be quickly made to do. If we do go with disallowing it, then that means that JSC, Moddable, and SpiderMonkey, at least, are the ones in the room that would have to make a change, We probably should hear from those representatives before making a consensus on that direction.
MM: My thoughts are only that we have a strong preference for a deterministic spec and one that all implementations converge on. So which way it's resolved for this particular issue, I'm abstaining, but definitely want to go forward in such a way that, if implementations differ from each other right now, that we all agree on something where we can have the same behavior.
SYG: Yeah, I would like to propose that we separate the question of changing Date.parse() versus deciding on what to accept for Temporal. Date.parse() is a lost cause, and I agree with what MM wants, I just don't think it's ever going to happen for Date.parse(). I don't think that is going to ever converge on something.
JHD: It sounds like based on the ISO argument that we should disallow the negative value for Temporal. The Temporal Champions obviously should step in and comment if they can. If we were to make that decision, and given that nonzero people read the current spec and assumed it was disallowed, then perhaps just clarifying that it's disallowed for Date.parse() and also just not accepting it for Temporal would make sense. I don't know if that—
SYG: Are you saying you don't want to separate the questions?
JHD: I think it's fine to do so, but I also think that there's value in even in Date.parse() making changes when possible. And this case, it seems like it would ensure future consistency. Even if it doesn't ensure consistency of current implementations.
SYG: The future is in Temporal, I think. My opinion here is that ensuring future consistency goes hand-in-hand with focusing our energy on Temporal and telling people to never use Date.parse() again.
YSV: I think SYG was going the right direction here with suggesting that we split this question and focus on what to do with Temporal. Because as I mentioned earlier, Date.parse() is a beast. It's not something that we really want to invest more time into unless we have an approach that will actually bring the browsers to agreement about how Date.parse() works. I'm not sure we're going to be doing that any time soon because we do have Temporal and I think it's a better solution overall for dates in JavaScript. As I said, we can change our implementation but it really feels like a Band-Aid solution for one of the many, many incompatibilities of Date.parse(), and it does feel like a lost cause. Basically, our time could be spent implementing other things and working on other stuff.
RGN: Temporal is seeking strong alignment with ISO 8601 and other date/time standards. So if this question is split, I would be strongly against supporting the year negative zero in that part of the library.
JHD: Okay, so it sounds like we have consensus that Temporal should disallow it. Is there anyone that disagrees with that? Are there any objections to clarifying the prose that RGN believes already disallows it in Date.parse() to more explicitly disallow it?
YSV: It may be good to hear from some of the other engines other than SpiderMonkey about their opinion here.
JHD: Sure. Is there anyone from Moddable or or JSC on the call?
MS: This is Michael from Apple. I don't know, part of me is like, yeah, we could do the work. It seems like a such a small area, given all the other incompatibilities already discussed. I'm kind of ambivalent.
BT: I think we're out of time on this item. JHD, do you feel like you have clarity on where to go here? I think we have consensus on Temporal.
JHD: It sounds like we could clarify the prose in the spec to disallow it in Date.parse(), but that maybe we should stop short of strengthening the test262 tests there. But if there's hesitation on that Date.parse() clarification, we can discuss it on github.
MM: I like the idea of just clarifying the text so that it's clear what the normal requirements are. And yes, given everything that people said, in stopping there. And certainly subscribe to the agreement on Temporal.
JHD: Alright, then I think we're good.
Temporal should not accept negative year zero Further discussion to happen on github PR
Presenter: Ron Buckton (RBN)
RBN: Hello everyone. Ron buckton from Microsoft and today, I'll be talking about the partial application proposal and the possibility of advancement to stage two. Some of the reasons that we've been looking into the partial application syntax are to add some additional capabilities to improve FP, style development. This originally strongly tied to the F-sharp pipeline proposal, given the advancement of hack style. There are some differences in how, the proposal has chosen the directions chosen to go. There's plenty more on that a little bit later the slides. One of the other reasons we've been looking at this is a syntactic alternative for function.prototype.bind with some additional capabilities that are currently present within that method. One is that you can fix arguments in any position versus bind which only allows you to fix leading arguments and you can fix the current reference to preserve the this receiver. So being able to take say o.f, as part of a partial application and preserves the this reference of o, versus bind. Which requires you to pass in the reference receiver, from the left side back into the call. Another difference that we're looking at. is that partial application is fixed arity by default. Which means that only the argument placeholders that you provide become new arguments and the resulting partially applied function, which prevents inadvertence passing of new arguments. We'll discuss some other ways that will handle that. And eager evaluation at the call site versus are functions which are currently lazily evaluated and as a result can have side effects that can occur for each evaluation.
RBN: So the proposal we've been discussing this several times before, one of the things that we've changed in since the last time we've discussed is the introduction, introduction of a Sigil to indicate. Partially applied call or partially applied construct. This was something that we were holding back on a bit due to wanting to have a cleaner and more concise Syntax for working with pipelines, but given the direction of the pipeline proposal is no longer a requirement as a result. We're investigating a infix style operator, that's actually a prefix to the arguments list, that indicates the partial call as part of this, the callee the Function, you're actually calling the receiver and any applied arguments are eagerly evaluated stored any, not yet. applied arguments can be replaced with a placeholder. The result of this is a partially applied function, which is actually an exotic bound function object that can be, then called later with missing arguments.
RBN: as I mentioned in the previous slide, partial application is designed to be fixed arity by default. this differs from bind which allows excess argument passing, but we are one of things, we've considering for some time, is the introduction of a bare ellipses, which would allow you to indicate a single place where any remaining arguments will be spread into the call, and I'll have more on that shortly. One final thing that we've been discussing and wanted to advance this part of this proposal in the long term was the ability to introduce ordinal placeholders to control argument order, allowing you to swap arguments to introduce new arguments and to repeat arguments within a partial application.
RBN: I'll provide some examples here that we can look at. So, when I talk about binding arguments in any position this example shows the ability to apply from the right rather than the left. In addition we can show that we can preserve the receiver. So in the example, we show that calling or a partially applying say hello to Bob, will create a function that when called actually maintains this receiver. Another value is the arity is fixed. So excess arguments don't get passed. So you look at the example here, if call are sent via array map. It'll pass not only the elements, but also the index And the array itself since the index is a numerical value percent will interpret that. And then determine that you're actually trying to parse for a different radix. And as rules result will end up with Nonsensical values or in this case, NaN, for the result. Whereas being able to partially apply from the right and having fixed are arity means that we no longer need to worry about the excess arguments, the the password through via the bear. Ellipses allows us to explicitly opt into function.prototype.bind style, excess argument passing, which allows you to do things like, Supply, leading arguments and the ability to reorder arguments or duplicate them. Some of the recent changes we've made to the proposal was the introduction of a prefix token to the arguments, one of the early concerns with partial application was the The Garden Path problem that an invocation at the start of the invocation that might have any number of arguments spreading across across multiple lines that you might not be able to know that, it's a partial call until some point you reach the placeholder that would have indicated the partial call. By introducing a prefix to the expression we now have the ability to indicate early that this is a partial application. and it also gives us a couple of additional capabilities for one. It makes it very explicit. What we are partially applying that it that the Expressions were applying are in the arguments position. It's not any arbitrary expression which matters for the eager evaluation semantics that I discussed before. In addition, it allows you to create partially applied calls that have no place holders. They have a fixed set of arguments previously, you would have had to have had at least one place holder to make the call partial. We also introduced ordinal placeholders, which again, allow you to reorder arguments to swap them swap positions to duplicate an argument, for example, the rest argument placeholder, which provides the finer control over how excess argument are will work. Another change is that we introduced was reintroduced support for new using some slightly more reliable. Semantics, We previously dropped support for it after some early discussion. And there's been some discussion on the repo as whether or not this is still about valuable something that I wanted to bring up and consider. So I do see a clarifying question from Surma. I wanted to point out that this proposal does not handle that. There's a discussion about a proposal from JS Choi that around binding this that's intended to have a mechanism to solve that and they actually these two proposals can work together in that fashion to allow you to take a free function. Bind it to an argument and partially apply certain positions, but that's something that think J.S.Choi will describe more in his proposal. One of the other things that we did was we removed, the temporal support. The last time you asked us this, I believe Mark Miller pointed out that it seemed a little bit too confusing that the syntax as so we decided to You remove that for the time being, if that's something, we decided reintroduce, it will most likely be in a separate proposal than this one. So, I wanted to go back and discuss the recent changes around the prefix token. Rip F style pipe lines. We would have preferred to not have a prefix. This would have made the syntax more concise and much more similar to what we're seeing now with the hex tile pipes, with the heck placeholder, now that they would have been essentially eagerly evaluated and even though the design of F sharp was that the right hand side and would have been a function that gets called with the left side argument, the fact that this is essentially a almost like inline. Evaluate the function expression that it gets, even though it's bound with those arguments. that then is called immediately. So it would have essentially seemed like the hack style type approach in certain cases. Now that the proposal for pipeline has advanced to Stage 2 with hack style, having a prefix is no longer a hardwire mints. Now one of the reasons we decided to put the prefix between Colleen arguments is to remove ambiguity when this has been has been investigated a number of different proposals. Both the smart mix and hack style pipeline proposals have considered this, with a partial expression syntax. This is basically a prefix token. The one that we were using at the time was plus greater than which basically marked an expression as being partially applied, that you could use the then hack style. Topic token to indicate argument an argument that would then be pulled out into an arrow. However, this prefix before the callee this prefix that would occur before. The callee doesn't exactly work. Well with eager evaluation semantics. So you can see in the example if you have a prefix token of some kind and then you call do dot and then from that called G with a token which part of this call was partial. Is it after G. Now the smart mix of hex tile were designed using lazy evaluation, which essentially is not much. Then an arrow function. So in specially, when the example here, the main difference is essentially one character plus a space. There's not much of a difference here. It can be a bit confusing from this perspective, looking at an expression that might be partially applied in this way and not realize that if this is lazily. Evaluated that every time you call the function increments, I just like you would with an arrow function. so prefix for a callee, doesn't really work well with eager semantics because the fact we can't really know which function we’re binding. The syntax is ambiguous. So we introduced this prefix token before the argument list so that we can make it very clear that what's being partially, apply as the argument list itself. so, the semantics are that it's similar to function.prototype.bind and it avoids side effects that occur as a result of re-evaluation something that you can't do with arrows and less, you essentially pull. All of the values. We write the arrow in such a way that it cannot have side effects, or you'll with other side effects, in the system that could mutate, the closure scope, or you have to pull out anything that has mutations in two local variables before you create the arrow function, which again creates Closure. One of the other advantages of eager evaluation is that we avoid refactoring hazards. If I had a result that was the result of calling a function that contains side effects in the argument list, and I wanted to pull that into a partial application. So I could use it multiple times with the same set of values. Eager evaluation allows us to ensure that each time. We call G. In this case that we're not incrementing. you've done the initial part of the evaluation, all of the Since become evaluated. And what we end up with is a bounded function that we can just call with the remaining argument and as a result, having the prefix for the arguments can remove this ambiguities and the previous slide saw this partially applied expression of o..f is a method called and then a method call of G. Not sure which is being partially applied. Whereas having the token adjacent to the callee and is part of the argument list, makes it very clear that it's the G method here that's partial. And another value of the prefix between callee is it's not much different than what we're already seeing with additional call-like syntax to proceeding for optional call or tag temporal Expressions. It's essentially just a new call like syntax. When the other recent changes I mentioned before was that we have introduced ordinal placeholders, which allows you to reorder arguments allows you to reuse the same parameter multiple positions. This can be very useful for adapting foreign APIs. So you have two packages that are loosely related that you want to call but they might take arguments in a different order, you have the ability do that type of adaptation, plus the ability to deal with if I need to refactor and introduce a copy of an of an argument to a position that you can just use the argument reference. And again, mention the rest arguments placeholder is another change that we made recently. So the fixed arity by default to be very clear. Shows the example, Parsons where excess values can be passed in Bear. Ellipses allows to have more of a bind like approach to specify that. I spreading in all of the remaining arguments in this position as a result. One of the things we want to avoid and it's we've discussed several times. among the pipeline's chanting route as well, was that we don't want to end up with this arbitrarily strange syntax of: I want to take a parameter in this position and spread the elements in or take the remaining arguments. You create an array here or all those things are essentially too complicated for this proposal. There things that if you need it, you can pull out to an arrow in the meantime, we would just say we only have the bear ellipses. Just is the indication of whether or not we are opting in or opting out of the excess argument passing.
SUR: I did notice just now a clarifying question from SUR about remaining arguments. I can address that as well. When I'm saying “remaining arguments”, I'm talking about any arguments that are not applied. So, actual values which are not placeholders. So, every placeholder that you introduce, it creates essentially a parameter binding for that argument any non placeholder excess arguments that you might pass in would then get mapped to wherever that element is. and, Let's see, so I'm not sure if that just clear enough. SUR can reply if he needs.
SUR: Yeah, that's my question. Thank you.
RBN: One. Semantics requirements are that we only allow a single rest argument placeholder within any partial application. So you can't spread it multiple times. It only occurs. Once again, it's essentially an opt-in to how excess argument passing works. This provides a convenient shorthand that is syntax for Function.prototype.bind without having to call the bind method in the event that it might have been patched by another API. So you can say f Paren, and that's and they bear ellipses. And this essentially saying this calling F by null or o.f with a partial application that has the rest placeholder, which is essentially the same as O.f bind O. This should be the same as oh, same as O,dot f bind. O, it also allows you to specify additional arguments after where the placeholder goes. This is kind of a less valuable feature, but falls out of how the placeholder processing works. So if you allow you to pick an argument from the beginning of the argument list and move it to the end, for example, And another the recent change that I want to bring is reintroduced support for new again. We're trying to preserve capabilities. You have with function.prototype.bind., So the same type of semantics works that you would have seen previously with bind. So if you have a class C and you call C dot bind passing in null, since the receiver won't matter, and two arguments, creating a new instance of that creates an object. That's say that is an instance of D. It's also an instance of C. Since By definition of how bound functions are exotic objects, work with partial application. You can do the same thing. You can invoke. See as if it was a call, and this creates the bound function object. It doesn't actually evaluate the call. then if you call new on that result, it's the same as it does today with bind where it will. Create a new instance. However, because the fact that we have the ability to use semantics we can Reduce the capability to add the new keyword as part of the expression. And as a result receive a funk, a function that when invoked creates the new instance, you can still use new with it, The semantics their don't matter as much because it's essentially the same as doing a function, that returns a new instance of that function. We've already seen examples of this today with Legacy es5 style classes that have a function that tests for whether it's been constructed and then creates a new instance. since essentially, new’ing inside of the function, or this replacement by returning from a Constructor. All of these are cases that where when you return new, you can return. Another thing that's new and the new will be outside, new won't matter quite as much. And then the last thing before I go to the queue was to discuss the hack style pipeline change. So previously we were strongly tied to a F# style pipes as a result. We needed to consider things like how we would handle yield await placeholders for colleagues Etc. The move to hack style pipes removes a lot of these concerns. We no longer have to worry about these types of positions for partial application. One of the other value is that, is that it makes the topic. And placeholder difference very clear visually and still provide some interesting use cases. So an example of a hack style pipeline that is mapping a array. Over a function. That's partially applied. We can see that. There's a difference between the tokens that are in use. And I'll get to the status describe where we're at right now, and then I can go to the queue. So we have the explainers up-to-date, the full, specification text for the proposal is available and I'll go to the queue before asking if stage 2 is something we want to consider.
Sorry, Ron, you wanted to go to the queue now. Yes. All right. First topic from Legend Dakotas. you can hear your little quiet for me, but I can still hear you.
CZW: I can see in the example is that is the new syntax preserves receiver, which makes it behave exactly like someFunc.bind(myObj). Does that mean it can be considered as syntactical replacement for function bind and doesn't clear the space for new syntax? Like I'm barbarita since that is a major case for find operator.
RBN: Yeah, there's a I think I mentioned earlier that JSC has a proposal for bind-this. Which we were discussing this a bit off line before Before TC39 these two proposals. Don't share a bit of every bit of overlap with how function binding works, but they actually complement each other in that in this proposal. You would say, o.f and the partial call which would essentially bind the receiver. Oh, in that position if you wanted to use it with a free function, you could use bind-this, which could take a object, the bind-this operator, and I'll let JSC explain this more in their proposal. But then use a partial call with that and then be able to bind the receiver of the function and any specific explicit arguments, you wanted to pass. So there is a use case for a scenario where we could have fulsome tactics support for what's currently evaluated with find. And that think will come as we discuss things like the, bind:operator. Brent said, answer the question. I can go to Sarah.
SHO: Hi everybody. I'm Sarah Groff Hennigh-Palermo. I'm a new delegate from Igalia. So if I do something really stupid, please forgive me. Anyway, I'm sort of concerned that changing argument orders is changing really a fundamental JavaScript agreement, right? That like argument order is parameter order and that is a known. There's not named arguments. There's not right typed multi method overloading like that argument order and parameter order are the same as like, a very fundamental agreement and as JavaScript practitioner, which is what I was doing before joining Igalia. I haven't even really seen a lot of cases where people are taking shortcuts around putting arguments in different orders. Like I am, I'm just not certain if this is motivated enough to be such a radical change. And so I would be interested in seeing more examples and more evidence before moving forward, that is a really needed radical change. In this case, you're talking more specifically about the ordinal placeholders, being able to reorder arguments, both the placeholders. And just the fact that partial application, right? If you use by and you still maintain that link between argument order and parameter order, but if you use this, then you can partially bind things out of order and that in and of itself, strikes me as a very radical change that, I'm not sure it's fully motivated in this case. Well, being able to apply arguments.
RBN: There's two things to this by default partial application as specified is fixed arity, which means that the arguments are in a set order. So, if you're not using portable placeholders, if you're not using the rest argument placeholder in, are just using the question mark and a partial call, the arguments are still bound left to right? They the difference is the arguments that you've supplied are essentially bound with values and it just allows to essentially cases, skip arguments that you want to bind or place arguments that you can't currently can't bind unless you completely rewrite the function or turn it into a arrow that passes arguments and And again the down side of the arrow is that all of those are lazy. The evaluated you're having to create closure. If any of the things that you're closing over are mutable, there's a possibility they could change up from underneath you and part of the value of the partial application proposal was to do these things eagerly. So that the evaluation you're Acting happens. Only once., early in the for anything in the argument list for the callee for the receiver Etc, in the cases of parameter argument reordering where you can use a ordinal placeholder. These are very specific and it's very nice use case that's that's designed around taking existing function that I have whether that's from another library or something that I've written and if I need to apply it in a different order, if I didn't pass the same you multiple times. there's a lot of different cases where or if I can just skip certain arguments that I don't care about the first three and I'm only want to pass just the last one. It saves you from having great, an arrow that passes undefined, undefined undefined, knees, and then finally the arrow argument passed in on the left. there it's designed around shortcuts and to give you a capability that if we didn't have the capability, then it would be that we'd run into later and both in these smart mix proposal and the hack style proposal when they were looking at Partial Expressions. There was this need and discussion around investigating having topics that allowed you to have like a carrot 0, or carrot 1,2 to the same type of thing. And these have been come, these have been investigated from different perspectives and different sources and all arrived at essentially, the same conclusion around. there are certain Niche cases that if you don't provide the ability to allow argue reordering that they can't use the feature for their use case and then have to again fall back to an error function. And there's nothing wrong with arrows. For say it's just that again, are functions release. The evaluated. So, there are certain cases where they're harder to use correctly than a simple and fix syntax. that all makes a lot of sense within the context of a pipeline, the reordering, such as the topic character in the half pipe lines, gives me less concerned because it's in a very limited location that the ordering is a sort of limited process for a limited season. and it's explicit where it's happening.
SHO: Why it's happening in this case, without seeing a lot of examples, where users are running into cases, where being able to reorder their arguments. Just to me seems like a big enough change. And I don't think I’ve seen enough evidence that like, in my personal work, I didn't see the evidence. I don't know that I've seen evidence out there that this is a problem. That is so big, that it is worth radical reordering. Yeah. Thanks.
RBN: All right. next up. We'll go to I've got more take, I'm going to promote the various other topics on this proposal versus Arrow functions. But go ahead, Mark.
MM: Yeah, so I want to echo and amplify some of the concerns that have already been raised. JavaScript is already a huge language, the JavaScript language is one, which we should think of it as has already exceeded its syntax budget. The unique role of JavaScript in the world is that it accommodates people of a great range of expertise for many people. Many non-programmers learn JavaScript in order to do something, on a web page, many people by that route learn JavaScript is their first programming language in gradually become more, professional programmers. Everything that we do, like this makes JavaScript harder to learn and the, answer will just learn the subset you're comfortable with doesn't work, when you're you're reading other people's code. Every time we add syntax, we make the learning burden of before you can understand other people's code, much higher. There's a variety of proposals. I want to raise this, not just for this proposal but as a theme for the entire session. There is lots of proposals in this session. but this one stands out a specialty where it seems like, like the problem of I have to use seven characters instead of instead of four characters to express something is treated as more urgent than the fact that we've already got too much Syntax for people to learn so I don't see that this solves a problem. Problem that needs to be solved. I think that the bar for adding new syntax of the language should be very high. I think that pipes with hack style, did meet that bar. So I'm not always against adding new syntax. I was very skeptical on that. And with the series of examples, they specifically with the hack style, that convinced me that it does meet that bar. Nothing here convinces me that it comes anywhere close to meeting that bar. I would I would find that. I would find it very unlikely that there's any modification to this proposal that would lead me to agree to let it go to stage two.
RBN: Well, that's the case. I find that unfortunate. The there's one of the goals for this proposal to provide a mechanism to give you some the ability to do some syntactic capabilities that you can't do with bind today and to deal with the fact that Arrow functions don't allow eager evaluation that there's a lot of complexity with eager evaluation semantics trying to get something that's eagerly evaluated to be something like what you can do with an arrow function. To you have to, again, pull out constants for any state mutations. You have to ensure that your the things you're closing over aren't mutable for a very simple cases. That's generally fine, for more complex cases, as you're building more complex applications, like building routers and express applications, Etc. All of these things in cases, people are using Arrow functions today closing over State and those are perfectly acceptable and very valid use case. As but, there are a number of cases for smaller operations where having to use Arrow functions, could be problematic. We're not the current semantics or current capabilities to do bind for good for binding ‘this’ in a reference either again require an arrow to capture or require. Doing like o.f by know, Etc. So there's we have all these cases where we use bind today that are somewhat limited, because of the fact that bind flies from the left and all of these things are right reasons why I had See if introduced I can find the slide. So this was the case where I was just guessing one of the things that we've seen that I've seen in a lot of applications that are written using not only is JavaScript. So if you're looking at someone that's using rxjs, for example, some of them might be using pipelines in the future. If I'm looking at even the typescript code base itself. We have a lot in typescript. We have a lot of internal functions that are very design. Heavily built compiler around, an FP style of development, especially for our scanner. Parser tree Transformations, Etc. So a lot of these one-off functions that we end up creating five or six different versions of it to pass different parameters. Where being able to do partial application of any kind of capture state would be very valuable. Any cases here is an example. If you're trying to do mapping and do some of Math style operation. I even Envision and have a proposal that's not yet. Been proposed providing operators, but functions for each of various operators. You could use it with in ecmascript to make mapping and reducing filtering, Etc. All much simpler without requiring a closure without requiring, this this possibility of side effects of mutations and simplify a lot of what you're reading. So it's much to read than passing a Arrow of X, comma, X into X. Plus 1. I mean, those are both. Those are readable, but we also have existing functions that are not simple math, operations, that you might want to be able to partially apply. And I find all of those to be valuable use cases for me to consider still approaching this.
MM: Okay. So if there are compelling examples that That would be interesting, but none of the examples that you've presented seem compelling, all of them are exactly things where I look at them and say what's the big deal? I would just write if I encountered that I would just write an arrow function. or just use bind? I haven't seen a single case where the example is so compelling that it's worth crippling the attempt of people to learn The Language by introducing new syntax. the you have on here is a perfect example of the, the pipe filter with the up arrow and the tilde, And the question mark. How look at how much new syntax were introduced? Into a language that already has too much syntax. We're talking about a real cost on the ability of novice programmers and people approaching the language. Has to look at others people's code, figure it out and start learning what they're doing and everything and you have to ask for each thing. are the benefits of the thing that you're seeking worth the cost in learnability to the millions of novices that keep coming into JavaScript.
we have a few more replies on this topic. I think it would be good to get to those. Yulia.
YSV: Yeah, I don't want to I don't want to exactly a pile-on hear my comments. Very similar mark one. One issue I have with when I reviewed this proposal is that the person thought that I had is a number of these examples can be done with arrow functions. And while I like the concept of partial application, and what it does for our language, many of the instances within JavaScript are often using bind to bind this. This is when this is something that you see very often. But I haven't seen examples that are sufficiently complex that would warrant like out in the wild that would warrant this special syntax, especially since we have Three or four, distinct proposals that are tackling this question of how to make a better bind in a sense. The pipeline operator in some ways is also creating a partial application approach for people. As is the bind. And there's another proposal that was Half a year ago, with the double semicolon here. Now, we have the tilde and the question mark, I would be very concerned to see all of those proposals go into the language and I'm already concerned about the complexity that we're introducing by discussing each of them without talking about this larger problem of I guess it's this larger bind problem, or this larger argument application problem. So, at the moment, I'm more confused about how we should really approach this problem or if we can formulate it that properly captures what we're trying to do here.
RBN: Yeah, I was gonna say that this is something that again J.S.Choi and I have had some discussions around the bind-this which was the original double colon proposal for this binding and how the two proposals can kind of work together around this binding, as well as partial application that they don't collide with each other in any way. I do think that I can understand the need to see more compelling examples, compelling examples are kind of hard to fit in the PowerPoint presentation. I do have a couple examples on the explainer and I'd be willing to look into more examples of what's needed to show compelling, use cases, cases, if that's necessary. Most of the examples here are essentially contrived, example is designed to show how the syntax Works without introducing the significant amounts of additional complexity.
YSV: Right now, complete examples, that sort of show how this is you how this solves a problem in the wild would be really beneficial. I also think that sort of like taking this broader question because the two of you talked about how these two proposals not could be written in such a way that they didn't conflict. I'm wondering if there is a broader question that we should be asking a broader problem that we should be answering that wouldn't require. Well right now we have three syntaxes for this, which is a lot. What if can we reframe this problem? And really tighten it into something that we can associate with JavaScript written in the wild that really solves a user problem?
I'm good. Next up is Shu. So, my topic.
SYG: So I personally agree with prioritizing readers over writers here, though. I have a concrete question. I'm still kind of missing at a Level, I guess on what the value, add over arrows. Is, I've heard. eager evaluation like, what is the problem with like if I were to use an arrow for some of these things you showed this example of this refactoring Hazard where you had an actual application and then you want to turn it into a partial application and it had and i++. Yes, exactly this slide. What is the value? Add for using and over an arrow? Like, if I were to make an arrow? I would just move the I plus plus out. What why is that such an issue?
RBN: It's more about. The I'm not trying to describe a hazard of arrows in general, but that's if you were to. Say naive. Idli, just put an arrow function in front of this in front of the You would end up incrementing. ‘i’ on each evaluation. It might, it's less of a very specific case of this is something that happens a lot, but more of a having this specific Syntax for partial application, makes it very clear that it's very clear that the arguments are bound. That's the placeholders, are the specific places. To require you to named arguments that you don't need names for. So instead you'll end up with an arrow that might have a comma, B comma C to in through pipe line arguments, or underscore 0, underscore one that cetera to pass in these arguments that you don't necessarily need names for. And if you needed names within a debugger for the function, they could theoretically be pulled from the function. That's partially applied. again, as was mentioned earlier, we don't JavaScript doesn't really do anything with names of arguments outside of how we handle the destructuring for object literals. So the downside of an arrow is you having to name things that are essentially argument goes in. in. argument comes out with 1 or 2 etcetera, into the function that you're actually applying or you're having to think about an ad in intelligent names and So, these are all decisions. You have to make, whereas, partial application, code takes those decisions out of the equation. You don't have to worry about what the names are for these things. You have to worry about pulling, I plus plus out of the function, call these things all just fall out from eager evaluation follow-up from the placeholders not requiring names. So in essence, it's designed actually simplify some the types of things you might do with an arrow without running into the same caveats of narrow again having to pull out the I plus plus
SYG: I don't see those caveats a I guess, I personally I disagree with that sense because I don't find partial application to be a thing that I would broadly. Apply. I say that. I suppose, I say that more as an implementer like moral hazard is kind of built into all language design, but I am I don't want really a feature who's point is to let new function wrapper proliferate, because it's not going to be free, but I guess that's a, that's beside the point here.
RBN: Say if you're going to introduce if you're putting this into an arrow function, you're creating a function wrapper. Anyways, it's not exactly exactly or even if you're using a function.bind, you're not, doesn't for you anything. If anything it closes over less State because it doesn't have to maintain a reference to the environment record,
SYG: but it encourages creating more functions. If it's like, I don't see what you have said is caveats in how Arrow functions are slightly more difficult to use and having two more thought go into. I don't really see those as issues. I think. Think it's a disagreement here, but I think OK, I've said all I wanted to say here. We move on to none arrows or it. Sorry we can advance The queue.
MAH: Yeah, so I mean similar theme here, but I would say looking at the presentation. I think it would have really been helpful to have side by side or maybe in the explainer side-by-side examples of what a solution with existing solutions like arrow or bind looks like and what it looks like with this new syntax. I watched the presentation and I was in my head trying to imagine for every case, what it would look like and it was really distracting to me, so being able to compare directly to see if there is a value or not with this proposal would have helped.
RBN: That's fine. I can bring this again later to the committee with additional examples. We have Waldemar on the same topic.
WH: I would like to echo the concerns about this blowing past the syntax budget for the language as a whole. We have too many proposals at the moment to add more syntax. I agree with Mark. This makes learning the language much harder. And so I find the benefits of this proposal are there, but they're minor compared to the cost. Now, if we are going to do function bindings then this proposal is probably the way to do it. There is one way that this handles new is broken, but that's something I put further down on the queue.
JHD: So, the three code blocks here. The “with bind” and “with partial application” blocks make perfect sense to me. They're perfect. They're like straight simple analogues. My concern is over the third block, which kind of captures the new intention in The Binding. This seems really weird for me as a language. We've despite adding new.target to account for legacy use cases. Where a function can be called or constructed and still return an instance. We have moved pretty strongly away from things constructing without explicitly using new at the call site, and this allows you to create a function that does not just produce an instance which in itself, it can happen all over the place. Right? There is not an issue. It produces an instance. It's an instanceof the function you just called without using new and that's weird. So, I love to see more motivation for that, that new capability, like I think, in other words, I think the first two things just kind of naturally already work in the language and that's not introducing a new thing. And it's I would be surprised if anyone concerned about those first two because that's the way bind already works. But this last chunk - I think that that is a very large change and I'd love to see more motivation for it, or understand the motivation for it.
RBN: And this is something that we've discussed in the pipeline champions channel as well in the past around. Basically, there's two things that are the reasons why I considered making the new keyword part of the partial application. One is that there is currently no easy mechanism to, if I wanted to call. Map array map on an array of items and passing in a constructor for a class that won't create new instances into the result. Because of the fact that it requires new. So you have to wrap that in an arrow function or have some other mechanism for that. We don't have a way, there's no like function or a function dot. Prototype.new that works like reflect construct or works like new again instance that we could pass that function where we need to do some type of mapping. So instead we have to use an arrow which goes to the second case. If you were to take a expression. was o 2, equals new c 1 comma 2 and then I decided, oh, I want to make this a partial application because I want to add a placeholder. This example doesn't use placeholders because it was trying to illustrate specific differences. But if I want to pass in a place holder, and if I were going to turn this into a narrow, I would say a arrow news, c 1 a for Sample. And again, this is the syntax that we were using for partial application was designed around the removing the argument list of things that you need to name the eager evaluation of the arguments that you're applying so that you can pull out a function that you can then call later. So if you were to take the same thing you were doing and just replace one of these with a placeholder, suddenly, if we don't have the new keyword, now, I have to remove the new keyword and it To make sure I call new somewhere else. Whereas, if I was using Arrow function, calling new on the Arrow function with throw an error because you can't do an arrow function. It doesn't have a valid construct. So the goal here was to emulate bind, but do something you can't do with by hand and with Constructors today, which is give you the ability to evaluate this in a as a call back position. Okay.
JHD: Yeah, I mean, thank you. I think as I've said on GitHub I think like () => new Something, would be fine there, even if that something is a partially applied function, like your const f here. But yes, thank you.
RBN: Yeah, the biggest concern that I get that I have two is if you look at f equals c with the partial application of arguments. I'm I'm calling this like, it was would be called as if it were a function, but if I were to call this as a function, it would throw type error because you can't call a class constructor, as a function, it doesn't work in the spec today. So not having it feels awkward from a call perspective because this is something you can't normally call it having this work. Just falls out. Because the fact that a class has a call, it just throws. Versus not having a call, Just like arrows don't have a construct would make this very awkward to use in those cases. cases. So again, all of these designed around trying to imagine what a refactoring might look like. As I'm evolving, the code from a current evaluation to a partial evaluation. Or normal valuation commercial operation.
WH: I read through the proposal. I followed the logic, but the thing that bothers me is line o3 on the slide, where you can specify new twice. And it's just saying it’s the same as only specifying new once. Without partial application, Function, new Function, and new new Function all do different things. Here you're doing new twice on g, but it only has the effect of a single new. So I would rather that not be allowed.
RBN: I would say this is more of an example of this is just again falls out of how bound function, exotic objects work. If I were to today, have a function of presents.
WH: No, it doesn't because you're assuming that the line which creates g creates something with a constructor.
RBN: It does
WH: Because if you're wrapping a new, it should only be a function and not a constructor. It's like a difference between Function, new Function, and new new Function.
RBN: This is not the same differences, new new function. This is more like if you had a constant g equals a regular function, not an arrow function that returns new C and you call that function G without new, you get an instance of C if you call you call that function with new. [Get an instance of C because whatever you created in the Constructor, it gets replaced with what you actually new’ed. Yes, that is like, that is the line F f&o for I think about G.
RBN: I'm talking about G as well, I if I could write this up, would as an example of where it's not new new functioned. It's not that I've taken this expression and placed it in the position of where G is. So, it looks like new new C 1, comma 2. I've produced a function. It's a function. that returns an object. So, when I call new on that function, it's going to evaluate the function return, the result, which is an object and its, which is not going to be. This that gets created when you when you call new, This falls out of how function evaluation Works. Currently if you're using just regular function and not arrows.
WH: So for f, I see this as doing a bind, which you can either call directly or use new on. The g is not like bind. g is like creating something which can only be called. So invoking new on it makes no sense.
RBN:I can paste an example into the TC39 delegates chat after this. That kind of shows what I'm trying to describe if that helps.
BT: We have just five minutes left. So I think maybe we can take this item offline.
WH: Yeah, I think we're talking past each other.
JSC: I know you've got bigger fish to fry with the stuff with the proposal right now, but I just wanted to raise two questions. One I think we talked a little bit about before: whether you considered making ordinals ordinal numbers required after each question mark placeholder. Just just to and getting rid of the implicit ordering with consecutive with consecutive question marks, just to make it. Clear that these question marks in referring to different things. I don't propose to strongly about that, but it's a something to at least consider. The other thing is a, a, whether you considered making the Eclipse has question marks made a question marks instead of just the base ellipsis. It's yeah,
RBN: I don't think I would use an ellipsis of question marks that it, I don't think that portrays intent, clearly. I think it would be more confusing than anything else.
JSC: Yeah, fair enough. Just something to consider. Yeah, but I know you got their fish to fry, that's but that's all I wanted to raise.
BT: Right, actually, with that done. The queue is empty. All right.
RBN: Well, it from it. Sounds like from the discussion so far. I need to do some more convincing before we can advance to stage two. So I won't ask for advancement at this point. I appreciate the feedback if anyone else has other feedback on the proposal if they could open issues the issue, tracker for the proposal. I'd appreciate if they have compelling examples that they feel would useful if they could add those to the issue tracker as well or in a PR to the readme. I'd appreciate it. And I'll do some additional investigation for some use cases where I would find this useful in various code bases.
Does not advance at this time
Presenter: Surma (SUR)
SUR: All right, so this is about module blocks and it's an update. I'm not looking for stage advancement this time around. Dan is on an extended leave. So it will just me championing. Obviously I have worked with many other folks as well.
SUR: Quick refresher. Module blocks adds a new syntax for blocked that our modules, which can bear after we dynamically import it to get that module into life, but also sent across to other Realms because they are structured cloneable being a foundation piece for all. All kinds of concurrency patterns, scheduling patterns. There's also Dan's proposal of Now, the name actually escapes me, Module fragments, which is completely decoupled and have decided to not merge them, which then I know then was talking about last time. We are not going to that mall. Your blocks remains completely self-contained and module fragments is Dan's proposal. that will keep will be working on. He will be using model blocks as a as a basis, but we should just be talking about one of the blocks in isolation or at least for now.
SUR: So what is new? Well, the first thing that happened is we have an HTML spec PR that integrates module blocks with the HTML module map, which has a couple of more implications. And I originally participated in integrates it with the dynamic import hook in the HTML spec. It's integrates with structure to serialize. In structure, deserialize, it does explicitly not as in contrast to what we originally pitched, not integrate with the work of constructing. I'm going to talk a bit more about that in a second. But yeah, so this this PR is there there is still a tiny bit of work to do for me for worklets. But basically we have tried to spec the entire education. So we kind of moved away from integrating module box with the work of Constructor specifically. there was more And more concerned about that. It will make one module per worker patterns, too easy. or almost seemed like the intended path forward where, you know, whenever you want to run a module, not on the main thread or in a different thread, you would just created a new worker and that workers aren't lightweight enough for this pattern. Somewhat as a coincidence in In the meantime, Ben Kelly opened a proposal where you can create empty workers and add modules to it, sort of similar to how worklets work. And so as of now, we are basing, or we are kind of using this proposal from Ben Kelly or we're expecting that to land and or hoping for that to land and if it doesn't, we'll have to figure out how to make it work. As of now we're basically saying like module blocks will integrate with the workless module add function. Function in the exact same way as they integrate with the workload at module functional.
SUR: but that's just, you know, a bit of news from HTML and more specifically if more relevant for this group, I think that we are adding a bit of sugar syntax where the above a module function is sugar for what you see at the bottom, which is a single function module that has just one default export. And the reason for that is that we the more we thought about it, the more we look at the prior art from other languages, lots of the threading paradigms and usage patterns use functions as their fundamental Primitives, rather than modules. for example, on the left, you have Swift on the right hand side, you have Kotlin with the very popular, you know, reactive programming pattern and they always have these individual functions that, you know, do some processing on data and you can schedule these functions to run on one thread or another on a background thread on the UI. thread. And I expect that we actually want similar paradigms to be possible in JavaScript if you imagine this with a full module block syntax, it would get quite noisy while with a module function. This will actually become possible and you know, the observe on or subscribe on functions graph. For example, take a worker or something. And so, yeah, we were kind of thinking that to actually allow all these patterns to be adopted. In JavaScript, even though of course, you know JavaScript can't adopt the exact or shouldn't adopt the exact same paradigms because, you know, shared memory isn’t a thing. And so different paths have to be taken but still the model programming, I think. I would want to see in jobs for that, makes it very easy to let you define a flow for data and then process it on the appropriate thread. So that's why we've decided to add the Syntax for module functions and that has also been added to the spec draft. That is in the repository. So we have module block all those. We have multiple function Expressions module, generator expressions, and their async counterparts. And if want to, you can take a look at those at the new features as it is right now at this URL.
SUR: the thing I'm here for actually is because I got stage two last time, but we kind of forgot to talk about stage three reviewers. I have since then gotten two offers out of bands from Leo and from guy Bedford who have offered and kind of agreed to be stage three reviewers. So I just wanted to put this on here that I have two people, if there's any more people who would want Strong feelings about this and want to review. You are very welcome to but I guess at this point. I actually even come to my stateroom years. years. So this was pretty much already, it and just quick update.
JWK: So I want to reject the module function sugar because I have two concerns about this new syntax. In the desugared form, it's easy to see that of all the items inside the module block {}, the curly braces are inside another lexical scope. The module {} isolates everything from the rest of the file, but in this shorthand syntax (module function (A, B = expr) {}), function parameters A and B are outside of the {}. Although we know initializers of A and B are running in another scope, it’s not being scoped visually. And I think that might bring confusion. The second concern is that, if you provide syntax sugar for exports default function but you didn't provide syntax export default expr. That creates an asymmetry in the language
SUR: Yeah, I definitely hear your concerns. I the scoping mechanism that, you know, the A and B in the sugared version are outside the curly braces. That's true. I'm I'm not sure how meaningful that is. Considering that the we already introduced a completely new concept here. I'm not sure if people actually read this with all the A and B are outside the curly brace. I'm not sure. That would be actually caused confusion the asymmetry, I definitely see. I was again, I was mostly by what I see in other programming languages, and the the concurrency patterns that they support, I'm not opposed to adding to making it fully symmetric. But at this like, also allowing module and module const I guess but I don't see that actually being used. So, um, I'm a bit torn on that but I definitely hear your feedback and I'm going to talk to some more people about it get some more opinions.
BT: I have a coming up on the 10 minute warning.
JHX: I have comments about Jack's concerns. It seems if a or b permit a default value evaluated in the expression of the it may maybe there will be some confusion or not. What's the so as I understand it should still be saved. isolated scope win in Montebello. Am I right?
SUR: I don't think I fully understood you. Can you repeat your point?
JHX: I mean if the parameter has a default value and identify and develop our expressions. The take should be be in the model block.
SUR: Yes.
JHX Yeah, so so I think, I think the make its it may be a some confusion because it's very like that is outer scope.
SUR: So I just want, okay. So with what if you if I use a default, if someone specifies a default parameter That's where actually the confusion could come in that. They default parameter value, which semantically be inside the module block, but it looks like it's outside while within the de-sugared version It would not be the case. Okay, I get that.
JHX : A second comment about it. I understand the motivation of model functions syntax. We want add syntax or but Even we have more syntax it seems still not good enough compared to other languages because it seems on the language that they are syntaxes much close to the arrow function in, but what we provide here is more like traditional. Function.
SUR: So yeah, I was thinking about also doing module Arrow functions to get even closer to syntax, but then I think someone point out that it might also cause confusion with this. I guess I have rethink what this syntactic sugar can actually be specified in a way that's consistent and meaningful, or if maybe the da the da sugared version is still, Is enough. Maybe I'll do some hypothetical Explorations there, but it definitely seems like there's some concern about the sugar.
JHX: Thank you.
MM: Last time, when module blocks and module fragments were thought to be reconcilable, there was some confusion about how static is the semantics of the thing we're talking about. There was one extreme which I think corresponded to the original module blocks. It's completely static. It's not linked. It's not initialized. At another extreme. You've got linked and initialized module instances. And then with the fragments there was there we seem to be dancing around the possibility of something that's linked but not initialized, which seems very confusing to me. So are these purely static, are these is ‘m’, hear something that in which no decisions about what it links to has been made.
SUR: Yeah, so I can't really speak to module fragments. But as of this, like ‘m’, in this case is, you could think of it as just a string of source code and it will only get properly evaluated by the time you call dynamic import. I think we were talking about the some things potentially being early like syntax errors, Potentially. Actually, that's what you act as a spec now. The body gets parsed at declaration time, but it doesn't get evaluated only.
MM: Just to explore with a couple quick concrete example, if inside your second example here, there was an import to something that was a completely meaningless name in this context, but the module block was sent to some other context where that import name was meaningful, that would all be fine because the module expression does not need to attach any meaning to the import declaration in this context.
SUR: that's correct, and is also intentional coming from the web world, you know, workers have a different Global scope than the normal web site. And that's exactly the kind of thing that needs to work. So it will get parsed syntactically, but all these things won't be evaluated on still import.
MM: Okay good.
MAH: we're obviously very interested in static module records, like this and I would definitely be a reviewer and I'll probably be working with KKL on that.
SUR: Cool. Thank you.
JHD: Just adding that I'd also like to be a reviewer.
LEO: I'd just like to express my support for these exported full sugar. I'm trying to just see like the potential usages, use it useful for this? I like to explore this and discuss with Jack works, but people who are like supposing that I hope we have like a async discussion in a thread for this proposal. It seems pretty interesting. And I can see some of the reasons. I like to more facts. in this case, the seems to be something that deserves a async discussion..
SYG: I had a response to Jack's concern earlier about the visual scope confusion. So I sympathize with a concern for sure, because we don't really have anything with Curly's especially functions, that kind of signal a break in the scope chain. Like, in this case where? We're a module function, you know, it's in a yet, uninterpreted module, an anonymous new module. So the way I've been thinking about it, maybe it helps for Jack and other folks, is if you think the thing like we can't really think of the curly brace as the thing that might break. I don't think we can, we can think of the we braces thing that breaks the scope and for because it if that were the case, case, the module block itself would very confusing because module blocks are open with curly brace. And obviously it's like it breaks the scope chain, but if you think of this as the module keyword as the thing that breaks the scope chain. If that's the thing that gets tired, that's what some folks mental models, then it's may be less of a stretch to think of module functions as something that breaks the scope change, but until we have that kind of mental model in place then yes, it will look very confusing. But I wonder if we can get there. I'm not entirely sold yet, but I think maybe?
SUR: Yeah, I'm definitely not giving up on it yet. I want to explore further and thanks for everyone who's offered to help. I'll probably write up an issue with the concerns and we can just continue discussion on GitHub.
NRO: Happy to be a reviewer, but I'll confirm this by the end of the meeting.
JWK: I opened an issue. It is possible to be a perf footgun that developers create a new module block every time. Even if they don't need to. I posted the example code in chats and you can see every time the user clicked the button, it will create a new module block in the memor. that module will never be never be recycled within an execution context. That problem isn't really resolved. I think, should we choose either side or, or try to support both sides with the solution proposed in the issue.
SUR: yeah, I promise you to get back to the issue and then we can continue discussion there since we're all the time.
reviewers will be: Mathieu Hofman (Agoric) Jordan Harband (Coinbase) Guy Bedford (OpenJS Foundation) Leo Balter (Salesforce) Nicolò Ribaudo (@babel)
Presenter: Ujjwal Sharma (USA)
Duration Format
USA: Hello, and welcome again. This time I am talking about duration format, which I might be biased but think it's a really cool proposal. So for if you weren't here during the last meeting, I give a brief presentation about some of the progress that we've made. And in that presentation is sort of tentatively promise. That I'd be up for advancement next time. So, here I am just to give a quick little recap if you've missed. We have new design for your format, will be finally spent a number of months struggling to find one that would fit all the edge cases and that would made all these stakeholders happy, but we finally have one. So it's, it's really nice. We have one that works similarly to the old design for pretty much all the common edge cases. It's easy to specify a base style. So if you want everything to be completely consistent, that's perfectly easy to do. All the old styles are supported so long, short, narrow, as well as digital. That was the controversial style. I was personally more or less convinced that digital is not worth keeping, but people helped convince me otherwise, so there's still all intact. Digital works as you would expect it to work out of the box. We had a number of problems where the edge cases with digital were previously not very good. But now we have addressed all the edge cases. So it should work in truncating a part of the value is still not supported because we believe truncating part of the duration is fundamentally a different value. There is a catch though if you, so maybe I'll talk about it in just a bit, but talk more. We now have new improved semantics. So this is what we improved. Now, we have unit specific styles, That is akin to date-time format. So now if you have experienced writing date-time format you know that for let's say months you can you know, have the full month name, you can have the short month name, you can have that displayed as a number and so on. Right? So we have a similar per unit styling option available. We have per unit distance. Display settings is so, so you can use this the settings to always display certain units. So I can say OK, I want these units to be always displayed and everything else would only be displayed their non zero and we also have defaults that just work. So just to give an example, if we explicitly set the style of a unit then that would be displayed by default always. Displayed by default. And then, you know, if you don't set the style, the display would be auto by default. So just an example. We have better support for fractional value. So this ties into what I was saying in the previous slides, that the truncation is allowed with a catch. We do have better support for fractional values and you can truncate the end of the fraction. To see how this works. We we have a bunch of examples so you can have a duration this if you remember, is the duration serialization format that is popularized by Temporal so so you can have a duration, you say 12 years thirty, months T, 12 minutes 34 seconds, and it would by default give you the short style And you can get the digital style, which would give you Why 34m for the years and months because it's trying to work on a best effort basis, but four minutes in seconds, it would fall back to what you would expect from digital if If you have digital (?) fractional digits then it would truncate some of the last sort of really significant digits of the of this value and it would give you 12 minutes 34 seconds. X. So, if 5 60 milliseconds, instead of 567, in this case, just to give a quick highlights over the semantics, we have styles for each unit. So there is a base style for the whole formatter. This is short by default, but you can change that Styles can then be customized for units. So once you have a base style for certain units, you can change the style. The default style for any unit is of course, determined by the value of the base style for simpler Styles. the unit style, same as the base, but for interesting, the more interesting style, which is digital, the value as you could have seen in the last slide was different based on, you know, what digital implies for that unit.
USA: Regarding displays you can configure when to display a particular unit. So all zero units are hidden by default. And when the style is, I was just saying, when the style is explicitly specify, they're always displayed by default.
USA: talking of fractions a little bit more consecutive units with the numeric style can be displayed as a decimal by using fractional digits. So you can display, you know, if you have seconds milliseconds, microseconds, and so on. And you have all of you can show them with display humor. them as all the single decimal and you can achieve this by using fractional, digits. The truncation of the value is not allowed in any way except for the truncation of the least significant bits by a fractional digit. So you can specify. Okay. I only need this number of, you know, digits after the after the decimal because it's usually important for the formatter to control these things.
USA: And so we discussed last time a number of open questions, so I want to talk about those first question that I discussed. Was should second be the smallest unit and accepted the answer that we came up with was no you can display all units until nanoseconds. It can be argued that certain, you know, values are not as, as useful in might not be used as much practically, but we wanted to include support for all. Control units. And so we have these, should we support fractional minutes and hours. The answer is not yet. So the current proposal does not include support for fractional minutes and hours because there were not strong enough use cases for them and there was not strong enough requests for it, but it could be done easily in a follow-up if requested. And if people realize it's something that everybody needs and so on.
USA: the current status is that we went through spec reviews. So just wanted to quickly give a shout-out to thank people who helped me with this: Justin, Frank, who also working on the implementation and all are amazing, Michael, Ron, and Ross. Thank you very much for the spec review. Thank you for the comments regarding the spec, some parts definitely of the spec. were not in the best position and think now it's in a much better shape than where we started. So thank you for that. All the comments have been addressed so far. So if you see any of the editorial comments that were raised by any of the reviewers and so on, are either already merged or are in a pull request. That is waiting for their final review. So, you know, everything is has been addressed so far and regarding, normative comments. There's none outstanding so for for a while at least there we have been in consensus that there is nothing more to be done normatively. So so that's great. Right. We spent a substantial amount of time figuring out how to do this. So, so I'm quite happy that we are finally happy with how it turned out.
USA: I'd like to ask for stage 3.
YSV: +1, looking forward to this going to stage 3.
USA: Awesome. I'm really happy to finally finish this one. It took a lot of time and a lot of design. More importantly, one of those areas where we don't have the data yet. So this one actually the design and the API precedes the data, but I think it's great because now we can start working on the data and on the ICU APIs and so on, keeping this in mind. So, I think it's a really great sort of move in which TC39 standards are creating this sort of upstream work and internationalizing more stuff. So that's awesome.
SFC: Thanks for giving this presentation. I'm super excited that this proposal has gotten to this point. I had a chance to review the spec. And since you said, there were no normative comments… I just had one question that the seems like a good time to resolve procedurally, which is that, when the fractional digits option is specified, that currently basically sets maximum fraction digits, but it doesn't set a minimum fraction digits, and I was wondering if that was intentional or if we wanted to have that option set both minimum and maximum at the same time, because otherwise it's not possible to display trailing zeros in the in the seconds or sub second digits.
USA: Right. Yeah, actually, I realized that now so it was intentional in the sense that it was my understanding of what people were requesting and you know far nobody as for for minimum so. So I just went with it, but I personally think after hearing you that, I, of course, wouldn't be opposed to it, and I'd be happy to, you know, change that to setting both the minimum and maximum. II. Think we can also, maybe split those two to two to give more. More control to people. I don't know. How useful. Would that be one thing we might do is we could, we could go to stage three conditional on resolving. This one particular thing about you know, what the options for fractional digits would be so I'd be open to all the options personally, but I don't know what the right answer is. If people are willing to discuss, Reach consensus on what they are correct. Solution is right here. Then I'd be happy with that as well. Okay, if no one else has feedback on that.
SFC: Yeah, I think, you know that that's a very small issue that we should just resolve in the processing of the stage 3 feedback, and I think we should see, you know, still go to stage 3. This is we just still go to stage 3 here, just conditional on resolving that small issue.
SFC: The other comment I had was to say that we do have the data. We just don't have all-in-one APIs for it. We actually do have the APIs for this, the data and the APIs, but they're not very well organized, and I'm hoping this proposal can actually set the stage for making ICU APIs that basically follow exactly what the specification is. Because I think that the reason that there does not exist a very cohesive duration formatting library in ICU is that it's very piecemeal right now, and no one has really invested the time it's taken to actually form a good API, like figure out how to answer the question, what is a good duration formatting API? What does it look like? And no one has really spent the time to answer that question. And, you know, this proposal has been in stage 2 for a long time because precisely because question is so hard to answer, and I'm really happy that we're finally at this point where we have a cohesive proposal that everyone can agree on and I think that this will set the basis for what duration formatting looks like. Not only in JavaScript, but also in ICU and other programming languages, so thank you. Thank you all for all the work you've put into this.
USA: Yeah. Thank you for your view as well. So, I actually had one question if you don't mind before we finish, which is, does the data include data for negative durations, or it just for the positives?
SFC: Number formatting supports negative values. I'm still unclear on exactly what the issue is with regards to formatting of negative durations.
USA: Right. The yeah. Yeah, the individual would just be for. yeah, I see what you mean. Okay. Thank you for your comment. I think. I agreed. Great, and I'd be happy to resolve it. Personally. I have no strong opinions. Can we ask conditional stage 3, on that one thing because a smaller group of people might be sort of more interested in that Niche discussion.
BT: All right. Is there any objection to moving duration for it to stage 3 modulo those, that side discussion, that's going to happen. I'm not hearing any objections. I think we're at stage three conditional on that, that discussion mentioned. Thank you.
BT: would be good to make sure that anyone who expressed interest in joining knows when that chat is going to happen. Can we put that in the notes?
SFC: If there's anyone from Apple on the call it might be useful to get an affirmative plus 1 from Apple just to make sure.
MLS: I think we're fine with it.
SFC: Cool, thank you.
- Stage 3 conditional on discussion of whether fractional digits sets minimum as well