26 January, 2022 Meeting Notes

---

Remote attendees:

Name	Abbreviation	Organization
Seungmin An	SAN	KAIST
Jihyeok Park	JHP	KAIST
Sukyoung Ryu	SRU	KAIST
Waldemar Horwat	WH	Google
Leo Balter	LEO	Salesforce
Philip Chimento	PFC	Igalia
Bradford C. Smith	BSH	Google
Robin Ricard	RRD	Bloomberg
Luca Casonato	LCA	Deno
Ujjwal Sharma	USA	Igalia
Chris de Almeida	CDA	IBM
Ben Newman	BN	Apollo
Frank Yung-Fong Tang	FYT	Google
Jordan Harband	JHD	Coinbase
Robin Ricard	RRD	Bloomberg
Pieter Ouwerkerk	POK	RunKit
Istvan Sebestyen	IS	Ecma

Presentation from KAIST research group

Presenter: KAIST research group (SAN, JHP, and SRU) & TC39 editor group (MF, KG, and SYG)

• slides
• JavaScript Static Analysis for Evolving Language Specifications: https://www.youtube.com/watch?v=3Jlu_jnHB8g (only for the people with the link because the last part of the video is under paper review)
• ECMAScript Debugger: https://www.youtube.com/watch?v=syfZ3v6JNg8 (publicly available)

SRU: Hi everyone. I am SRU. I am a faculty at the School of Computing at KAIST. Today two of my students are going to present our recent work on automatically generating various tools about JavaScript programs from ES, the language specification written in English. So, first JHP is going to present a very brief version of his PhD dissertation, and then SAN is going to show you a pretty cool tool, a debugger for ES.

JHP: I'm JHP, a PhD candidate in the Programming Language Research Group at KAIST. I will briefly introduce our recent work with these slides. I will first explain why we started this work, and which tools we have developed so far.

JHP: Initially, I was one of the developers of a JavaScript static analyzer called SAFE maintained by our group. So, the left side is the first paper of this tool and the right side shows its open-source repository in GitHub.

JHP: However, it was too labor-intensive and tedious to develop SAFE to me because the overall development process was manual.

JHP: To develop the JavaScript static analyzer, we first should carefully read the JavaScript language specification called ES to define its semantics formally. And then we should abstract the semantics for static analysis.

JHP: However, the more critical problem is that we must repeat this process when the specification is updated.

JHP: Until 2015. It was not a big deal because ES was rarely updated. However, it has been getting worse because of the massive update in the ES6 version and the annual release cadence of ES. So now most JavaScript static analyzers cannot support the latest versions and still focus on the ES5.1 version. So, this is why we started this work.

JHP: Instead of the manual process, our main idea was to automatically derive static analyzers directly from the ES specification.

JHP: So, this is the overall structure of our approach. We developed 4 different tools and I will briefly explain the role of each tool with simple examples.

JHP: First, JISET, which was published in ASE 2020. It automatically extracts a mechanized specification from a given version of the ES specification. We call a specification mechanized when it is both formalized and executable. So, JISET is a kind of automation tool or reference interpreter such as Engine262 or Narcissus.

JHP: This shows JISET, which mainly consists of two parts. One is the syntax extraction part that generates a JavaScript parser and the other one is the semantics extraction part that compiles abstract algorithms written in English to the corresponding functions in our intermediate representation called IR_ES.

JHP: For example, this is the syntactic production of JavaScript for array literals. JISET automatically generates JavaScript parser code written in Scala based on the given syntactic production. Therefore, this generated parser can parse JavaScript array literals.

JHP: For the language semantics, we utilized the well-organized writing styles of abstract algorithms. First, we defined a new intermediate representation called IR_ES to represent the English sentences written in this style. Then, we carefully designed 118 general compile rules to compile each algorithm step to its corresponding IRES instruction. So, JISET automatically compiles this abstract algorithm written in English to this IR_ES function.

JHP: For example, it shows simplified compile rules consisting of parsing rules and conversion rules.

JHP: The algorithm compiler first tokenizes a given English sentence.

JHP: Then, it parses the sequence of tokens based on the parsing rules on the left side.

JHP: Finally, it converts each sub-tree to its corresponding IR_ES components based on the conversion rules on the right side.

JHP: As a result, it successfully compiles about 95% of the algorithm steps to IR_ES instructions.

JHP: And, the mechanized specification can correctly parse and execute all applicable test programs in Test262 after filling out the remaining parts in ES10.

JHP: So, this is how JISET automatically extracts a mechanized specification from ECMA-262. Then, we developed three different tools using the extracted mechanized specifications. The first extension is JEST, which is a conformance test synthesizer using a given mechanized specification. This work was presented at ICSE last year and received a Distinguished Paper Award.

JHP: JEST consists of three modules that behave differently depending on the extracted mechanized specification. First, "Seed Synthesizer" synthesizes a set of programs as the initial program pool using a syntax-directed program generation. Then, "Program Mutator" repeatedly tries to construct a new JavaScript program and only adds it to the program pool if it increases the semantics coverage in the specification. Finally, "Assertion Injector" modifies JavaScript programs in the pool to generate conformance tests by automatically injecting appropriate assertions according to the semantics described in the specification. Using the synthesized conformance tests, we detected conformance bugs in both specifications and JavaScript engines.

JHP: The core part of JEST is to automatically inject assertions to JavaScript programs using the mechanized specification. For example, at the end of this program, the variable x must have three according to the semantics described in the specification.

JHP: Therefore, JEST automatically injects an assertion to check the value stored in the variable x like this. JHP: We defined seven types of assertions related to exception or abort cases and values stored in variables or object properties.

JHP: Moreover, we also support object property descriptors, orders of object properties, and even internal methods and slots in objects. JEST automatically injects such seven types of assertions into given JavaScript programs.

JHP: Using JEST, we successfully synthesized 1,700 conformance tests from ES11, and we successfully detected 44 bugs in four different JavaScript engines including V8 and Graal JS and 27 specification bugs in ES11.

JHP: We also developed JSTAR as another extension of JISET. It performs a type analysis for the specification. This work was published in ASE last year.

JHP: A type analysis for specifications is really helpful to detect specification bugs. For example, consider this abstract algorithm for the Math.round built-in library function in a specific commit version.

JHP: Since it is a built-in library function, its parameter "x" can accept any kind of JavaScript values.

JHP: Then, the "ToNumber" algorithm converts "x" to a number or an exception. Since the question mark filtered out exception cases, the variable "n" always points to a number.

JHP: However, on lines three and four, the variable "x" instead of "n" is compared with several numbers with inequality operators.

JHP: So, if a Boolean value is given, the semantics for this abstract algorithm cannot be defined because it tries to compare the given Boolean value with numbers on lines three and four.

JHP: Therefore, we need to fix these bugs replacing the variable "x" with "n" on lines three and fouur like this. If we can perform type analysis on this specification, we can detect such type-related bugs earlier.

JHP: So, we developed JSTAR to perform type analysis on ES specifications. To detect type-related bugs using the type analysis results, JSTAR contains four different checkers for references, arities, assertions, and typed operators.

JHP: For the past three years, from 2018 to 2021, 864 commit versions existed in the GitHub repository of ECMA-262. So, we performed type analysis on all of them using JSTAR and successfully detected 92 type-related bugs. Among them, 14 bugs were newly discovered specification bugs that still existed in ES12. So, we reported these and they were fixed.

JHP: Finally, JSAVER is an extension of JISET, which automatically derives a JavaScript static analyzer from ES. This work is currently under paper review.

JHP: JSAVER takes two inputs: a mechanized specification and a JavaScript program, and it performs static analysis for the given JavaScript program depending on the extracted mechanized specification.

JHP: Therefore, if we want to derive a JavaScript static analyzer for ES12, it is sufficient to fix the first argument as ES12 and freely pass any JavaScript program as the second argument.

JHP: For evaluation, we derived a JavaScript static analyzer from ES12 via JSAVER and tried to analyze about 18,000 applicable Test262 tests. Existing JavaScript static analyzers, such as TAJS and SAFE, soundly analyzed only less than 30% of them. However, the derived analyzer soundly analyzed all of them with reasonable analysis precision and performance.

JHP: So, this was a brief introduction to our recent work. Now, we decided to develop a new framework from scratch by selectively importing code from our various tools and refactoring them for a better usability and performance.

JHP: So, this is our new framework called ESMeta, which stands for a metalanguage for ES specifications. The original JISET directly compiles abstract algorithms into IR. However, we think that it is better to define a high-level metalanguage to represent ECAM-262-style English sentences and compile them into IR for further features. Now, the current version of ESMeta supports only extraction of mechanized specifications. But, we are actively developing this framework. So, hopefully, we will support other features soon, including conformance test synthesis, type analysis for specifications, and JavaScript static analysis. Moreover, we are also actively developing a debugger and an editor for ECMA-262. And, one of my colleagues SAN will show you a short demonstration of the draft version of ES debugger now.

SAN: Hi, I will briefly introduce an Alpha version of our interactive ES debugger, which extends the interpreter of JISET. If you want to try it by yourself, please follow the instructions in the slide. Okay, I’ll start a demo.

SAN: The main purpose of this ES debugger is to help understand how ES executes a JavaScript program. So, as like a normal debugger, it controls the execution of a JavaScript program and visualizes the state of execution with respect to ES.

SAN: On the top, there is a toolbar to control a debugger. I’ll explain each button later. On the left, there is a simple text editor where we can write a JavaScript program, on the center, there is a specification viewer, which shows you a single abstract algorithm in ES. It shows the name, parameters, and steps of the algorithm. Before starting a debugger, It shows the main entry point of our debugger, which is RunJobs from ES10. On the right, there is a state viewer. It becomes enabled after you push the “run” button in the toolbar.

SAN: First of all, you must provide a syntactically valid JavaScript program and push the “run” button above. If you make a typo like this and press the run button, you will get an error message like this. I’ll fix this and push the run button. So, now the debugger starts and all the buttons are activated.

SAN: The basic execution unit in this debugger is “step.” “step” executes a single step in an abstract algorithm. If it invokes another algorithm, it goes into the algorithm we just have called. So, here we are in RunJobs and I’ll press “step,” then the first step of RunJobs is to perform the InitializeHostDefinedRealm algorithm. So, I’ll press the step many times to show other functionalities of our debugger. [steps] Okay, I’ll stop here. Now, you may want to know what value is bonded to each variable in this algorithm. If you click the environment Tab on the right, it shows you their values. As you can see, O points to the Function prototype, P has the string value “caller”, and “desc” points to some address in the heap. Every address value starts with a hash character. If you want to know the object pointed by desc, expand the heap Tab and type the address you want to know. You can see there is a property descriptor object.

SAN: Next, you may want to recall which algorithm calls this DefinePropertyOrThrow algorithm. For that, you may expand the call stack Tab on the right and freely navigate Its calls stack. RunJobs calls InitializedHostDefinedRealm, it calls CreateRealm, it calls CreateIntrinsics, it calls AddRestrictedFunctionProperties, and finally it calls DefinePropertyOrThrow. And you can also see the environment of each algorithm like this.

SAN: Now, we are at the initialization stage of JavaScript execution, which I want to quickly skip. For that, “step-over” and “step-out” buttons might be useful. “Step-out” executes the remaining steps of the current algorithm until it meets the return step. So, if you press the “step-out” button here until we reach RunJobs, now the “step-over” button might be useful. “Step-over” executes single steps in the current algorithm. It executes all the steps in the callee algorithm if it invokes another algorithm. So, if I press the “step-over” button, here it executes all the steps in RunJobs and goes to the next step in the RunJobs algorithm. I will press “step” many times. [steps] So now we are at “ScriptEvaluation”, which is the actual execution stage of our JavaScript code. Suppose what we really want to know is how addition works in the ES specification. Then, we may expect that the evaluation of the AdditiveExpression algorithm might be relevant. Thus, let’s open the ES Breakpoints Tab on the right and set a breakpoint to the AdditiveExpression algorithm. You can set breakpoints to any abstract algorithm. Then, if you press the “continue” button, the debugger executes many steps until it meets the breakpoint. When it meets the breakpoint, a blue alert pops up. And on the left side, an additive expression x + y is highlighted, since we are evaluating that expression right now. The remaining things are “js-step”, “js-step-over”, and “js-step-out” buttons. As you can guess, these buttons are for controlling the execution of the debugger with respect to JavaScript source code. For example, “js-step” executes many steps in ES until it reaches the next line. [demos] So, when the debugger terminates, a green alert pops up. You can restart the debugger anytime by pushing the cancel button and the run button again.

SAN: That’s all I prepared for today’s demo and finally I will briefly talk about our future plan. So, there are four items. First of all, I want to add more debugger features. For example, showing JavaScript states by refining ES states states and adding time stamps for reasoning resume and suspend steps, especially for generators. And then I plan to show relevant Test262 tests for each algorithm step and show the type of each variable using the type analysis results of JSTAR. And finally, I want to add a live editing feature, which directly edits “spec.html” in the specification viewer. Thank you for listening.

WH: Hi! I've been involved with doing something similar with ES for more than 20 years. I've read your papers. I have a number of questions. I see in the JISET paper that you do not support “minor language features” such as non-strict mode, modules, early errors before actual execution, and such. Have you implemented those since writing the paper or are they still unimplemented?

JHP: They're still not implemented.

WH: I'm also looking at your formalism. I can't figure out how you would implement something like the shared array buffer memory model in this.

JHP: It is a reasonable extension but we currently do not consider expressing that memory model in our formalization.

WH: Yeah. I'm really impressed with what you've done! You've kind of done the reverse of what I did on the committee back 18-20 years ago. The existing spec was partly machine-generated and verified at that time. I can give you a link to a bit of that:

https://www-archive.mozilla.org/js/language/old-es4

WH: The original web pages are gone, but there are partial history archives of the original machine-generated spec, which is where the current grammar formalism for ES came from. This was machine-generated by Common Lisp code which I wrote. It would validate the lexical, regexp, and syntactic grammars and some of the semantics. We don't use that much anymore, but I still occasionally run it on things.

WH: I've read your papers and have some questions about how you handle the grammars. Specifically I didn't find any way of how you can validate the grammar to make sure it's not ambiguous. I think that if you actually run a program which happens to be ambiguous, you might detect that, but do you have anything which actually validates the grammar to make sure that no ambiguous programs exist?

JHP: The parsers JISET generates are based on an extension of PEG, parsing expression grammars with one-lookahead tokens. So, we do not care about the ambiguity because, in parsing expression grammars, by definition there is no ambiguity. While the JavaScript grammar may have some ambiguity, we do not consider that issue. We simply assume no ambiguity and parse JS programs with one-lookahead tokens.

WH: Yeah, so that means is, if there is an ambiguity bug in the grammar, you will do something but what you will do probably depends on the order in which you wrote the rules or some other implementation details. You will not be able to find the bug in the grammar.

SRU: That's correct. PEG uses ordered productions.

WH: Yeah. The formalism I had made sure that it was order independent. You might want to take a look at this old archive. That webpage is hopelessly out of date, but this is where a lot of the current grammar formalisms in ES standards came from.

SRU: Yeah, that’s ES4!

WH: I still use this to validate proposals sometimes.

SRU: Thank you for the pointer.

PFC: First of all, I can hardly express how amazing this work is, this is really impressive. I sat through the presentation with my mouth open the whole time. So thank you very much. My question is: I'm involved in writing the specification text for some proposals, and I'm wondering, some of these tools look like they would be really useful to proposal authors. Do you have an idea of how feasible it would be to run tools, especially JSTAR, on proposals that haven't been adopted into the specification yet?

JHP: I believe that is possible. We’re currently reimplementing the toolchain and I hope the new framework is available in a month. Then, I think we can apply our technique to new proposals.

SRU: Yeah, we believe so. When we wrote papers, we applied our techniques to proposals well, not only the complete specification versions, but also proposals. After we had a meeting with the spec editor group in November, we decided to re-implement our toolchain because we used Scala heavily and because as you know, the paper writing with deadline involves - how can I say, rush implementations and duct-tape implementations. Now that we are looking forward to integrating our tool into the specification release process, maybe all the tools or some parts of the tools can be integrated into the TC39 process. We hope to have the entire toolset ready in one month. Then you can use our tool for your proposal writing. Helping proposal writers and eventually spec writers was actually our main motivation.

PFC: Okay. Thanks. That's great to hear.

MM: First of all, I also want to express my extreme appreciation and really awe at what you guys are doing. I am really really enthused about it and so is everybody in Agoric. I want to mention a few things. First of all, since you are running Test262, using your executable specification, presumably you can directly derive from that what the coverage of the spec is by Test262, what clauses in the spec might not be covered by any Test262 test?

JHP: Yeah, we measured the semantics coverage of the specification using Test262, but as you know, our executable specification does not support all the English sentences in the spec. So, even when a Test262 test program covers some English sentences, our executable specification may say it does not because it does support the entire English sentences.

SRU: We can improve how we measure the coverage of the specification using Test262 by revising the units of coverage metrics. In addition, we can even generate more tests to cover the entire specification. We hope to use or integrate our tools to generate more tests for Test262.

MM: So, two more things I want to mention. One is that TC 53 is using as the base JavaScript for standardizing JavaScript for embedded systems ‘hardened JavaScript’, which has no [non-]strict mode. So TC 53 might be able to find all of this tooling useful earlier than TC39 because of the absence of sloppy mode from the TC53 standard. The other thing I wanted to bring up is that one of the, you know, purposes of having a formalization is to be able to make proofs and with regard to other attempts of formalizing the following nice juicy first target for a substantial proof. Is that the spec states a set of object invariants that should be true for all objects, whether exotic or not. And then specifically for proxies there's an algorithmic specification of the enforcement that the proxy system does of what behaviors the handler can bring about. And we believe, but have never been able to verify, that the operational specification of proxies succeeds at enforcing that proxies cannot violate the object invariants independent of what the Handler behavior is. So, is it possible - do you think it's a reasonable target to try to prove that the proxy enforcement mechanism enforces that proxies cannot violate the object invariants?

JHP: I think it is possible to use our tool to prove those kinds of things.

SRU: Proving or injecting assertions. And proving as JHP said, I think it's highly possible for us to go in but we haven't done it yet, but I think it's a very likable future plan.

MM: Okay, great. Yeah. I was really bringing it up not to get a yes or no answer but to put the idea on the table so we can explore it. And the other reason why I think this is interesting is that YSV and I in particular have been very interested in writing down other invariants that we believe are true for the language currently specified. It would be wonderful if we proceeded to try to write down those invariance, the endurance that capture non-local things that cross languages to be able to verify that the inverse that the hypothetical invariant is an actual invariant with regard to expect. So that would be tremendously useful hints to go in that direction as well.

SRU: Right. So, the main point of the entire toolchain is to generate a formalization from a specification written in a natural language called English, right? So as soon as we have this mechanized specification from ES, we can generate various tools including parsers, type checkers and things like that. And a verifier that you just mentioned is another example. So I think it's doable. It's possible and I think it's a very good possibility.

MM: Thank you.

YSV: I'm just +1ing what Mark said. It would be very good to have a way to explore these corners of the spec that have enabled certain properties of JavaScript programs that we may be immediately aware of so that, you know, we can discuss and determine whether or not those are properties of the language. That should be kept.

BN: First, this is truly amazing work. My mind is blown. I tried to get screenshots, just to remember the slides and then was just taking screenshots of every slide. So I stopped. Clearly you enjoy a challenge, shall we say, but I wonder if you have any general recommendations about, you know, ways the specification could be restructured or formatted differently to be even more machine-readable so that your tools don't need to handle as many special cases?

BN: And then the next question is also mine, which is just about whether you're comfortable with these slides being shared among co-workers or not - happy with any guidance there. I'm just really excited and I want to show people.

SRU: We are more than happy to share our slides so that you can just do whatever you want to do with them. About the specification recommendations, now that we are re-implementing our tool, we are trying to use as few rules as possible and we are planning to add pull requests about irregular grammars and things like that. As you know, in ES, many chapters are written very nicely, but some chapters like regular expressions were written very differently and that they required special rules for our parsers. So previously when we worked on JISET in the beginning, we had to write them manually in various cases, but now that we are in a slightly better position, we'd like to ask the spec writers to revise those sentences to be more like the common style.

BN: Yeah, I think we would welcome that. Thank you so much.

SRU: So as someone asked before, we think that this is going to be especially helpful for proposal writers because the things written in the specification already are pretty good, but proposal writers are maybe new to this spec style and they make some mistakes or they just use different style and if we have this kind of lightweight checker for them for writing style or even an IDE to suggest better style, then it's going to be helpful for the spec writers and proposal writers.

WH: Can you post the links for everybody to your papers and any demos?

SRU: Yes, will do. We are going to share links to our papers and slides. For the demo, we are going to make a video of our demo and make a link to that.

WH: Thank you! Yeah. And regarding the regular expression formalism, I first wrote it in runnable spec code. Back then people didn't like having code in the spec, so I translated it back into more of a free-form and this is where the regular expression chapter came from. It originated as a lambda calculus code. And now we're going full circle translating it back into a formalism.

LEO: Okay, I just wanted to highlight how much I am amazed and impressed by this. I just regret that we are not recording this presentation because I want to share with some other people who work with me, but this is a big deal. MM mentioned a new dimension of coverage for Test262. Historically from what I can tell and I have some experience with, Test262 is among the biggest pain points for all the works done as Test262 because we always need to go subjective saying when the coverage is reasonable for the test that we have. And this is too subjective because there is no other way so far. And what you bring might mitigate this immensely. So, thank you so much. This is like, I am very surprised in an optimistic way. I am impressed.

SRU: Thank you. Thanks a lot. And I think we are going to make videos as soon as possible and make them available.

USA: So, first of all, I had to respond to Leo. if I understand correctly there is a recording from the SES call. So I think you might be able to get that.

LEO: Oh, that's good.

MM: It wasn't an actual SES meeting or rather it was not during the normal time slot, it was somewhat different. So the video of that has not been publicly posted. There was some private discussion in there that needs to be redacted first which has nothing to do with technical content. So after gathering permissions, and doing redaction, I'd be very happy to post that. So yes.

SRU: Thank you.

USA: Yeah, I also wanted to say that. I really love the idea of more spec linting, so I'm really happy with the project and I hope we can integrate this somehow in the workflow and get some linting going. I was also investigating. Sorry for taking it off their topic here, but I was also considering how we could get it running for ECMA-402. So there were a number of suggestions in Matrix that I'll try, but yeah please feel free to reach out if that's something that you care about also.

WH: What would it take for us to be able to use the debugger which you demoed?

SAN: It's available in the JISET repository.

WH: How can we run it?

SAN: I'm going to add a link.

SRU: His slides have the instructions.

YSV: So, I understand that there's this presentation. There are certain constraints around it. The slides can be shared. I don't know if I can represent all of the ideas that you went over in these slides accurately, and it makes me feel like, oh man, I really wish that we had some way to capture these fantastic presentations that we have from universities because right now, I'm thinking back to past presentations. We've had from INRIA and also from the University of London and I'd love to go back to those too and sort of, reflect on the work that was done there. And look at the work that you've done here. So, I'm just sort of putting this up to the committee, maybe in the future, we can sort of think about how we can keep an archive of this kind of work because it's really fantastic.

WH: You can read the papers, they're excellent!

YSV: Also very true. Thank you for the suggestion WH.

MM: So let me just point out that we do have precedent. With regard to speakers wanting to record a presentation and recording it. In particular. I've done this several times where I think, I think the way I structured it is a good precedent, which is I inform everybody before the beginning of the presentation that I'll be recording and that questions that are asked before I break for questions in the discussion of those would be the recording to recordings on intended for public posting, get everybody's permission to proceed and then at the end of the presentation itself when I brake for general questions, at that point I stop recording so that we can have a normal unrecorded discussion. I've done that several times. I've posted several of those talks. nobody's ever objected after the fact. So I think that's a useful thing to do and I think it's good to remind people especially new speakers that might not be aware that we do have that as a precedent for managing this issue.

RPR: Okay, great. So, I think that that's the end of the questions. So, thank you very much to all of our presenters. I think this was an excellent presentation. In terms of committee feedback, what you're hearing here, this is the committee in ecstatic mode. This is, this is the maximum that I've heard in terms of positive feedback for a presentation. So, so thank you very much.

WH: Yes. Please do submit pull requests for anything which makes your life easier.

RPR: Yes. Yes. if anyone has any scheduling requests, the best way to do that is to send them into the agenda before the meeting and then that will factor into how we schedule things. Do we move these tools to stage 4.

KG: Also I want to emphasize you don't necessarily need to open PRs, you should feel free to just open issues and editors will address them. We also care a lot about the consistency of the specification. So you shouldn't feel obligated to do all of the work to fix it. Just pointing out that there is an issue is also very helpful.

Holistic discussion of TC39 dataflow proposals

Presenter: J. S. Choi (JSC)

• JSC’s diagram
• JSC’s article
• Tab’s article
• subsequent overflow ad-hoc meeting

JSC: Okay, great. Hi, everyone. My name is Joshua Choi. I am a delegate from Indiana University. This is going to be an hour long discussion about multiple proposals. So right now we have maybe five or six proposals, with which some representatives have called concerns about. Because they're concerned that they overlap in various ways. And so it would be good for us to consider this whole problem space at once. This problem space, you could call it ‘dataflow’, ‘linear dataflow’, in which values are being converted. Our various operations are being applied to the values and their chain, and they're changing. So, for instance, there's the pipe operator proposal. There are various binding proposals, like, bind this and extensions, and there's also a new One that tab has proposed that I haven't haven't added to this diagram yet, is callThis. There's partial function application syntax. That's RBN. I recall and, and there's also extensions from JHX. which is, which is like also another binding thing. And lastly there is a proposal that I'm planning to make that stage 0 Function.pipe. So, there are now six proposals that are in this problem space. And so represent multiple Representatives have expressed concerns that there are redundancies between these and they would like us to consider whether we should reduce redundancies between proposals, or at the very least, We should holistically consider to whole problem space because as we all know, we have a limited syntax budget in the language, we don't want to do a tragedy, like a common lisp etceteras. Cetera, so the way each of these proposals tackles a slightly different problem. So, even though we lump them all together in the same ‘dataflow’ space, they each do different things. Like, for instance, partial function application. It's really relevant to, although it's relevant to some of the data flow proposals, Its core goal is not data flow per se, the other proposals are more in that realm, especially the pipe operator, which is the most generic of them. So this diagram tries to illustrate how the complex ways that these proposals overlap for instance, the pipe operator overlaps with a lot of other proposals, even if they're in more verbose ways. It's very versatile, But that also means that because it's less specialized it might be less concise but something's something's cases the I go through each of these proposals, briefly one by one. And then I will briefly go over where they overlap, and then I would like to open the floor to discussion about the approach we should take. There's a fundamental question to the plenary that I want us to discuss too, which is We need to make a choice between allowing proposals to stand on their own merits versus considering cross. When we consider cross-cutting concerns. How bad is it, that a proposal is redundant with another proposal. How important is it? That we change proposals to not overlap with each other or is it okay that there's more than one way to do it? so, basically, there's a tension between the goal of reducing redundancy between features. There's only one way to do it versus letting proposals stand on their own merits without considering other proposals, which may encourage. There's more than one way to do it. Tim Toady, Tim toting stands for there's more than one way to do it. It's an abbreviation. So I'm going to go through each proposal first. Really quickly.

JSC: First is the pipe operator, The pipe operator has a long and storied history. I wrote a history document on the history.md. On the repository if you want to get where we got, but right now, it is an operator that you use the bar symbol than greater than, the left-hand side gets bound lexically to a certain to a certain special symbol the You can think of it, like, a know nullary operator that placeholder. We call it the topic records, that that, so the left hand side, gets evaluated becomes the topic and gets bound to the topic reference. Which in this case. It's the pound sign. We're bike shedding about that. It doesn't really matter in this discussion, so it could be a function call. It could be an array literal. It could be an array literal, in a function call, you could have properties. It could be whatever expression on the right hand side. So it's very versatile. And the reason why this may be good is because it allows us to to rearrange the word order of deeply nested Expressions. you know, in everyone's code there exists some just about all code bases, have like deeply really deeply nested, expressions with deeply nested parentheses, so it can be really hard to follow the the order operations with them.. Especially with prefix/ infix, suffix operations. so and like, including function calls with multiple arguments, so people could try by naming variables for each intermediate step, but people don't do that and And the and one big reason why they probably don't do that because naming is hard. So people just do Nested, it really deeply nested Expressions, which is fine, but it's also more. It's also maybe Harder to read, especially when word order is mixed up and also over relying on a variable names, especially, when names might end up being just the name of the operation you're doing. Anyway, might make things even harder to read some people might argue. That's why we're where the pipe. Operator may be good. That's why I'm a co-champion of the pipe operator. operator. The pipe operator is very versatile. Just about every other proposal. Does something that the pipe operator can do , all be it they might do it more concisely. While the pipe operator might be slightly more verbose because you have the topic reference, but it's still less verbose than trying to think of a variable name. And then, and then, and you ended making a const decleration or whatever. So, that's the pipe operator. It's at stage 2 right now.

JSC: Next, I would like to look at function.pipe. If you could hand their function, pipe is a really simple, is a really simple proposal. This isn't syntax. It's just a function or a set of functions if you will. It works on unary functions only so it allows you to chain unary functions. A lot of people in the community have wanted this. If some of you may recall that the pipe operator has gone through a long history of going back and forth between emphasizing tacit unary function calls. So this, because a lot of people like creating pipelines based on unary function calls. So this a simple API that does it without syntax. It's simple to it's simple to do, write, but it's also simple simple to use. and it would accommodate quite a few coding Styles without necessarily encouraging constructing, a lot of unary function calls, which I know some Representatives have been concerned about. So it's really simple. You the first argument to the pipe function is the initial value and then all the rest of the arguments are unary functions, and they get called consecutively on the value the result. There was written the pipe function Returns. The result of the Last function, it's basically function composition, but you're applying. There's function.flow. There, might like that's also in the proposal, which is just function composition without immediately applying the for the, an initial value. It creates a function call back. So as you can see function function.pipe and function, the pipe operator overlap, but, you know, overlap in a In a way that is simple and is arguably small. Yeah, you can do it through syntax, but it's also nice to have a function that that works on unary functions. the examples they're marked with FP, that's function.pipe. There's an abbreviation next to each title and po that stands for pipeline operator, that that's an example with pipeline operator. So there are two pairs of examples there that are equivalent. There's also an open area of overlap there that I will get to when I talk about extensions. If we could go to bind this.

JSC: The bindThis, operator Works in a different space, but if it overlaps in certain ways with the pipe operator, and with some other operations, the function.prototype.bind call method. Is very very common people use.call in various ways it for various reasons. It's a and I'm talking about binding the this value to that this receiver. for a function, you know as everyone knows in JavaScript. Every function has a this binding, a this Dynamic binding and they use it in various ways. So sometimes you want to conditionally, flip between two methods, and you need to use a certain this value on them, or sometimes people will use array prototype, methods or object prototype methods, and they applied that they need to apply them to certain this values. .call is very common. We you can view our methodology. We did a corpus analysis. You can see it on the purple on the GitHub repository for this proposal. We exclude a transpiled code, even with that .call is more common than .push. Its more common that than dot set for the various datasets you have in the 10,000 most popular. Unloaded npm packages at least up 2018 or whatever.call is really common but doc calls clunky and it's clunky for two reasons order and verbosity word order would also, you know instead of having a receiver.method and then arguments, you to do method.call( receiver), and then the arguments, that's very clunky and very A verbose. So, and for a very common method, like .call, it Maybe we're optimizing for in the language. Furthermore. There's a it also would be good. Syntax would also allow us to not have to depend on, on the specific function. It wouldn't be forgable. It wouldn't be modifiable in the global. In the, in the function,.prototype of global. So, so, you know, so there you see. Receiver double colon to double pulling can be byte. Shedded owner dot method creates creates a bounded function and then you can call it as usual. Yes. Sure. Yeah. So so there ‘BT’ is bind this and you can see examples where beat the PO examples, the pipeline operator examples solve also solve the order. It's just more verbose, the ‘ex’ examples. There are for the extensions proposal, which I'll talk about next to the bit. So like for instance, if you have, if you want to call with one argument on your receiver, receiver::owner.method, that method and, and you can supply an argument and and this would this would optimize for the very common use case of using .call. Now this gets a little more complicated when you consider another proposal, an earlier proposal called extensions.

JSC: Extensions is a stage one. Proposal from JHX. It. It does a couple things it. Introduces several new syntax has involving either methods property descriptors. So fine, but we're bind this. When you omit arguments in the function, call. It creates a bounded function. Whereas extensions does something slightly different instead. It does something with property, descriptors where it assumes that if you omit a method called like, arguments in parentheses that you're trying to use a property descriptors’s getter. So like if you extract a property descriptor from some owner object, and if you want to apply that, it's getter to a receiver. You can do that with extensions. You can do that with bind this to or with the pipeline operator. It's just, you have use the .get method. You can also do this with the, with Setters too, so it allows you to use assignments in text. The logistics of the setter syntax TAB, and I are not quite sure of yet, but the goal is to allow to property descriptors on arbitrary receivers to to an assignment syntax on them. This isn't a common use case right now, but the idea is that it would become more common. With that box on the right, bind this extensions and pipeline operator, all overlap. That's that's where bind this, extensions and pipeline operator All overlap with varying levels of conciseness, but they all have the same word order at the very least. So, like with the pipeline operator with a pipe operator, you can just use .call with the extensions with the bind-this. this operator You use, you can use syntax without having to use duck calls. So it also doesn't depend on the function, dot prototype, and with extensions, you don't have if you have a property, descriptor object. You don't need to say dot. Get. And you can also use assignments attacks for dot Set. extensions also comes with a couple of other things, like it comes with a special that that column on the right on the right. there. It comes with special extraction syntax. This is a statement level thing that uses an import level syntax to try to extract property descriptors from owner objects, which is the same as using object.get on property descriptor. It it also has a polymorphic syntax that doesn't involve the this binding at all. It's it's a little complicated. But perhaps explain verbally, but basically the right, the right hand, if you there's a trinary form that allows you to specify the owner object especially and depending on whether that middle operand, the owner object is a Constructor or not. It's a Constructor then you It calls, binds and uses the property, the sorry the constructors prototype to extract method while with if it's not a Constructor, it assumes that it's a static function that doesn't use this at all.

WH: Looking at your chart, I don't have all of the various proposals swapped in at the moment. So I'm having a hard time figuring out what some of these things actually do. It might help if you also listed how you would write something in existing ECMAScript. Or what the thing does.

JSC: Yeah, I will be so I would be happy to modify the diagram to have that in In the meantime, in this meeting. Did you want me to go more slowly step by step, like over?

WH: Yes.

JSC: Okay. in that case, let's go back to the pipe. Operator first. So WH, basically, that like take a look at that first example, value pipe to this one is equal to Value just gets yeah.

TAB: Okay. Where the all say then if the pipe operator works for you. I think every single one of these has a pipe operator version, and that should be the most straightforward one. That's just normal JavaScript, but expressed in pipe syntax, but, you but you know, like numerical function. Body, at least so it's not like existing JS. I understand. But it's close the closest we have here.

WH: Yeah, that's kind of what I have been doing. But what I can't figure out is why you'd want to do some of these things.

JSC: So like so, you know, WH if you a look so think about we have Real world examples in the pipe operators repository. Like we have like maybe ten, deeply nested expressions are really in code bases, where people didn't bother, you know, a science, sequentially, assigning, intermediate variables for each step of some transformation. So if you take a look at the repository, you can see examples in the wild of such deeply nested expressions and then using the pipe operator. We would entangled we could untangle them into linear into linear lists of Transformations that are fairly flattened. So and which are arguably more readable for. Take a look at that.

WH: That's not quite what I was after in asking that question. I understand the motivation for a pipe operator, but for some of the extensions things, some of the —

JSC: Oh, you mean the other proposals, okay.

WH: Yeah, I don't know why these are interesting use cases and specifically since, because of grammar, these things will often still be nested. You cannot put an arbitrary expression in front of :: and have it parse. So it'll still be nested.

JSC: So I am not the champion for the extensions, proposal JHX. That's why I was hoping he'd be here and if you are here, JHX feel free to add yourself on the queue, but I could, I could do my best to explain for JHX. I am the champion of combined business tax is present. to WH about some of the. Well, what am I? Could you point out some of the specific use cases, you'd like hacks to, to, to elaborate on like, like, are you, are you would you like him to elaborate on property? Descriptors or Y or the polymorphism between Constructor? Not Constructor objects or whatever, or are you just confused about how it works, how extensions works?

WH: I'm confused. So let's pick the example that’s now in the lower right of the screen now. I don't see why you'd want to write it in the Ex form rather than as just a regular plain old function call. I don’t see the motivation for including that use case.

RPR: One thing. I just like to check here is we're halfway through the time box and it seems like we're going oh, into detail on just just one these is your choice as to whether we go into the deep dive here, but whether it is, you know, you get to decide what. Best use of this time.

JSC: So, I would like to limit the explaining details of proposals to five more minutes overall so we could give another minute to to, to extensions JHX. If you could really brief about getting a love, little, be brief.

JHX: Yeah, design. So extension. Actually is not that, that flow, it can be for that flow. Just let me cause the, it's a method essentially To just like a method. The only difference the normal methods is look up from the receiver, but the extension method of the, you get the extension methods from the Declaration. or it's look up the method of from the []? here. So, it can be used as a book for that flow. It just because we currently could use the method chain as for that. So in this example, in this is specific example, it could be used as that, but don't think it's, you couldn't not you, if you don't want that, you could not use as that. So anyway, I are trying to give updates of extenions in next meeting. So maybe I can explain more in next meeting. Thank you.

JSC: Yeah, okay, so that sounds good. I will say that extensions and also bind-this. Have been called out like anything involving. this bindings. Have been out of concern that their overlap with the pipe operator And with also with a partial function application have been called out of concern because they can be used in this way and they may encourage use in this way. It's such that may encourage use to use in these more linear Expressions. Sorry, WH that we don't want to really get into the nitty-gritty of like this the like exactly how each thing works, but I do want to emphasize that. Yeah each, it's true. each proposal. It's true. What JHX said the extensions proposals main purpose isn't for data flow. and that's also true of bind this and also true a partial function application. However, they have been called out as as concern because they do overlap. They can be used in overlapping ways. So it's important to examine how they overlap and how they don't overlap like if their purpose isn't data flow, then should we change them to overlap less,

JSC: and that gets into the bigger question that I want the plenary to consider which is how important is it that proposals don't overlap. Versus how important is it? That we think about proposals on their own merits without thinking about other proposals. We say, we want proposals to stand on their own merits, but at the same time, we care about cross-cutting concerns and excessive redundancy is bad, but is it is it completely bad? Is some okay. How much is too much? There's more than one way to do it versus There's only one way to do it. Um, these are fundamental questions that the plenary should think about. And so the fact that extensions overlaps in some ways with function that function.pipe with and definitely a lot with bind this and also to some extent with pipe operator, and also find this overlaps with the pipe operator, and with partial function application syntax, these questions, these questions make us, Force us to think about, okay, should we try to shrink them so that they overlap less? Is that desirable? Well, I happen to actually kind of agree with WH in that. I don't know. I'm not sure about some of the motivations of extensions like I'm not sure why in a world with the pipe operator for instance, instance, if the pipe advances, why we would want the syntax, like, in the lower right there, or in the upper right? Having having said that the extensions proposal could drop those JHX will give either way. JHX will give an update. plenary, bind this and extensions probably are mutually exclusive. They tackle different things bind-this thinks about bound functions and doesn't care about doesn't care so much about property. Descriptors. Just use .get or .set and then there's partial function application, partial function, application tab, Partial function application. It's it overlaps with in a certain way in that. You Can use it to apply to get a to extracted method from an owner and have it bound to that original owner. And that's the area overlap. That's the only reason why included and And that method expression, sometimes shows in data flow, proposals. I mean, sorry in data flow use cases, and also method extraction is common some time in the DOM events stuff and such like that so that that's why it's included here because there is some overlap TAB has floated stage 2 proposal called call this the call this operator, that would be like bind this, but wouldn't let you bind functions and it wouldn't rearrange the word order. So like and and Argument, is that it's good that it doesn't rearrange the word order because that means it doesn't overlap at all with the pipe operator or partial function application. So, you know, tab, if can zoom out, again, showing the overall diagram, these proposals all overlap in different and complex ways, and they can grow or Shrink in various ways to try to reduce overlap. The main gist It's, I want you to take away from this diagram though. Is that the pipe operator is very generic and covers a lot of stuff, but it just might be a little more be somewhat more verbose. In addition, the this extensions and also call this with again, call. This isn't on the diagram. They all try to address the use case of the this receiver. And bind, this, and extensions also tries to improve, the word order. So to speak, call-this doesn't try to do that. You can look just Google ‘tab call this operator’ and you can see what it looks like. So, and there's also like function.pipe which overlaps with pipe operator in a small way, And there's extensions which cuts across find this and also overlap slightly. We wave function that pipe and and, of course, all of this is within pipe operator, and then there's function partial application the side and then it overlap slightly with the pipe operator, operator, and the bind-this operator, use case. This is the state of the six proposals that we have right now. It's kind of, it's pretty complicated. I tried to simplify it as much as I could. The overall gist. Is that the pipe operator is very generic and covers all of these. Then there are other. There are other proposals that overlap in smaller use cases in various ways that the pipe operator, arguably. Also improves just more verbosely and with that, the plenary should think about: is this bad. this good? How bad is it? When two proposals overlap at all? How much overlap is acceptable and, and we, and, and we can go from there. Okay, ‘don't want to ship our org chart in the language’.

[time-check]

So this is wait before you talk about apart. Sorry. How much time do we have left? Send so you've got 20 minutes in the time box, but there has been a request that we finish on the, on the hour for lunch so that this would continue for 10 minutes after lunch. And if there's still room in the on the third day to work on this more than we could talk, perhaps we could, could make a it overflow the session for this. This is the third day if you wish to do this tomorrow, I would say I'm sorry to pull you commissioned an ad hoc call so it is plenary. I suggest you use the time. Okay, that's fine. Go on Waldemar.

WH: Our job as a committee is to make a unified language. If we're shipping our org chart by making proposals that don’t integrate well with each other then we failed at our job. The other thing I have to say is that, while some examples in the chart here benefit from new syntax, for a bunch I'm unconvinced that any of the new syntaxes are better than the existing syntax. The chart didn't list the existing syntax. All of these also overlap with the existing syntax. And for some of these, the existing syntax is the simplest thing to do.

JSC: Yeah, I totally agree with that. So the existing syntax should be in there. There. I would say that some of the some word orders are not possible in the existing syntax at least without defining variables. Like for instance. It is not currently possible to do nested function calls and have the initial value be first in the code. Unless you use a variable declaration, having said that the functionality is still is possible. We're trying to improve word order there, but there are a bunch of use cases in here. Then that, yes, the status quo language could do it and in a good word order so that's oh, yes. Yes. I totally agree, there.

WH: The word order is not the only important thing. The word order is not necessarily determinative if you need to parenthesize the first thing in order for things to actually parse. So in some cases even though the expression you want is first, you still need parentheses to actually put an expression there.

JSC: That is true. If it's a complex expression that that is true, depending on the precedence. JHD has something.

JHD: Yeah, I just wanted to respond to WH’s comment that our job is designing a unified language. Absolutely our job is to make sure that all parts of the language try to work well together, but JavaScript is multi-paradigm. If you approach it from the lens of each of those individual paradigms, there's lots of ways that it could be better. If you're an OOP/inheritance person, or Functional Programming person or, a number of other paradigms, etc. I'm equally not convinced about all the proposals in this diagram either, but I'm very convinced about some of them. And It's not necessarily our “org chart” if we are shipping features that make specific paradigms better. We do that with classes frequently, where we have made classes better and that doesn't help anyone who has a different paradigm from classes, but it helps those people, and it helps the language when seen through that lens. So I think it's useful to play with it. While it's useful to look at the overlap of all these things (and I hope no one is taking this diagram as to mean “all of these things are coming necessarily in these forms”) but I think we need to be careful to consider people coming from each of those individual perspectives

JSC: Yeah, so there's a although it might be there may be a correlation between who's proposing something and different programming paradigms. They are different as JHD says, as with JHD, I don't want, I don't want this entire chart to being the language. I don't want every proposal on this track to being the language. I think some of them are mutually exclusive. Having said whether it's a big deal. that both pipe operator and partial function application, who are buying this for our in the language. I don't think that's a big deal. Even if there's some overlap because they may tackle different paradigms. But at the same time, that is a question for the plenary, is that how much overlap is bad? As WH said, we are trying to make a unified language.

MM: Okay, I think that for, I want to express very strong agreement with WH. How as TC39 our responsibility is to be the steward of the language as a whole Is and the language as a whole. already too large, and too complicated and confusing. Unfortunately, because of the constraints were operating under, as we all know as a committee we cannot remove things. We cannot improve the quality of language by making it smaller, but starting from a position, where we have already groan, well, past a decent-sized, most proposals will subtract more value than they add and with regard to the question that you're raising. Should we consider the proposals individually or to what degree should we consider them together. Up through es6? We had no, we did not have this proposal process and we needed the proposal process to scale, but there's a real cost to it. es6 and es5 which are the two ones that Two exercises that I participated in before the proposal process. We consider the entire language organically. And in particular, I remember with es6, we have lots of proposals on the table and we did an overall strategizing session, where we were voting and did multiple rounds of winnowing and try to come up with a set of features that together made a coherent progress for the language and cut all sorts of things that individually look plausible, cut them as not fitting and not being worth adding in that next step of the language. So with regard to the specific. So the big pathology of The Proposal process, is it puts people in the position of feeling that progress is adding something that the nature of the proposal process, gives psychic rewards to have your proposal added. I have certainly experienced that myself and it obscures the overall cost to the language. So all of us have to be guardians of that overall cost. And when there are, there is overlap and cross-cutting concerns. Absolutely. We should highlight that and we should understand that we're fighting against the pathologies of our own process to fight that and therefore we should fight for that even harder. With regard the particular set of issues that are on the table. I'll just go ahead and force the issue and say I am not willing to approve more than one of these and therefore they are exclusive. There's enough overlap as shown here that I have that. um, and in any case, the syntax budget is already, we are over. what should be the normal syntax budget, my starting position is zero of these are acceptable. I've been in that position for a long time. I eventually became convinced of pipe alone. This diagram helps explain why it's fairly simple. It has no runtime implications and it has a lot of power has a lot of coverage for one met one additional mechanism. I've never fought that any of the other syntactic ones could go forward. I should say that function.pipe and function.flow are not syntactic, so I won't include them in my only one constraint here and that's what I wanted to say.

JSC: Thank you. Dr. Miller. Yeah, your point is well-taken about. I recall you're the author of the tragedy in common lisp. And yes, JavaScript is indeed large language and we need to be good stewards of that. So, being choosy when it comes to which proposals and the proposal process itself, avoiding the pathologies of that is very important And that's that's a big reason why I put this diagram together. Yeah. Yeah. All right, I think That's true.

RPR: Thank you very much. So we will continue with this topic after lunch.

YSV: The reason that I am concerned about the image that we see here is because what we have with pipeline is a sort of super-powered proposal which, you know, it, as I see pipeline it is allowing functional programming to utilize one of the benefits of object-oriented programming, which is chaining and it does so in a very natural way, but we see it being sort of extended into this space: of what is object oriented programming, the bind this operator? Now we have the argumentation that this is about improving the word order, but I believe that for object-oriented programming the word order and The ordering of operations isn't really a problem. And that it's either not improving the situation in that case, or it's making it worse. That said, I think that there is an additional issue I'd like us to think about as language designers, which is that constraints are a source of creativity and a source of thinking harder about problems. So, one thing that I liked about the previous version, the simple version of the pipeline operator, was that it was more constrained. It didn't have as many superpowers, As this does specifically it only accepted function calls and even in the most minimal, and especially in the most minimal version. It did not even accept await. Now, I want to highlight one feature of pipeline, which is that it allows you to change the underlying type that you're working on and it even encourages this because it is part of the syntax. So for example, you can go from a list and immediately from that list. It is supported that we go to, you know an element of that array or some other very different data type. There's no encouragement to split this into two separate variable names, which I believe had, you know, people could, of course. So one discussion we had is that people can write whatever kind of ugly JavaScript. They like JavaScript is a very provisional language. It has a lot of flexibility. However, continuing to add more ways in which the language is provisional isn't necessarily a benefit. There comes a cost with too much freedom in the language and this is my fundamental concern that we see here. That said, I have not been blocking pipe. I just want us to think about this and to think about why we would add a feature that has so much flexibility when in fact constraints may benefit us. The other thing is that I would say if we include this into the language, then I would argue against MM’s point that we shouldn't include any other proposal from those listed here in particular. I believe that their that while pipeline covers, the use case of bind this or some form of it, and it doesn't have to have new syntax attached is an independently useful concept for programmers. working the object-oriented Paradigm. That pipeline doesn't solve very well. And I think that's it.

JSC: thanks YSV, So just just going really quickly backwards. I'd encourage everyone to take a look at TAB’s call this proposal to, which is like bind-this except Slightly different and it doesn't overlap with pipe at all, but it solves the use case that you of making dot call the really, really common method. the really, really common object oriented method much more ergonomic. I'd encourage everyone to look at TAB’s call this operator proposal, at stage zero, Although our JHD has argued that that we could just change the bind-this operator to be like, call this. and it and the problem space has already achieved stage one, whatever. We want. next thing is that it is true that you can obfuscate code by hiding data type changes. When you, when you step through a transformation, I would point out that's not quite unique to the pipe Operator, but is in fact present. I know I told you this already. It is present with dot a method chains and it is present with sequential function calls, like including unary function syntax. Anyway, I don't think that's quite unique to the current pipe operator before that is a more fundamental issue of prescriptivism versus universalism. I think SHO might have a topic to touch on that, maybe in any case, it's 5 operator. Tries not to be prescriptive whether that's a good or bad thing is, is, you know, can be the plenaries’ opinion. It is certainly true that people can write that difficult to read JavaScript code with the pipe operator, or with any, or with dot method calls, or with whatever and not split stuff into variable calls. That's just, yeah, that's a fundamental skill. That programmers need to have and some programmers of them. Unfortunately, don't whatever you want to add it to the language. It depends on the benefits of fluency with like function calls, outweigh the risks, but either way, I don't see a way to fix this while allowing an ??? function calls without Arrow functions and await which I know isn't a big deal to YSV. You'll be upload like a in any case scenario function calls. I don't see a way to fix that, at least without partial function application, which has is running into it’s own problems.

SHO: So, thank you, JSC for doing this. I did want to address. A little bit YSV point about the pipeline operator, to me. It does not vary much, which is why it seems like it does a lot, right? It is a lightweight thing that fits in with Expressions as they exist, and I personally have a lot of issues with bind-this, you know, but more to the point think, and sort of the problem with this discussion is on the one hand, we can talk about the specific proposals in front of us, and whether we like this proposal, on the other hand, there's the bigger question of how we group those. proposals, right? So I think the question of universality versus prescriptive - that JSC brought up in the article, is a very good framing for this, which is more desirable, right? That's like an open question, likewise. You can look at foregrounding this and not foregrounding this right? Some people's issues with bind-this include right that write free-this functions and pulling this. Something that people find very confusing more forward into the language, a good choice, right? That's the way we can look at. We could look at the concrete proposals, for the usage of each of the items and discuss whether, you know, the actual places that these various proposals would be used overlap In fact, and I think it makes sense somewhere to draw lines that we can't have everything, but I think if we're not talking about the bigger reasons, we're drawing those lines and coming to some consensus on that. Then we're looking at things like drawing lines based on the time and like, write that certainly isn't fair to say that. Well. If you wanted more FP support, I guess you should have gotten all those proposals in before people improved classes, right? That's not like a desirable way to make decisions. I think going forward. I mean I write like it doesn't seem like a way to get to a good and useful language. Overall, I think it be useful for us to spend more time talking about the broader goals and coming to some consensus on that. Because otherwise, time you take a group of proposals and try to pick, which one is the most important. It's just going depend on the particular framing you picked up at the time and that's it. it. Thank you.

JSC: How should I try to arrange an ad hoc meeting at the end of plenary? Like, so should I like, would it be like overflow time or what? I have to arrange something Outside of plenary. How should I work on the fourth day?

RPR: I mean, how what we can I'll tmu and we can work ahead and set that up, but he'll be simplest if we just reuse the meeting time that we would have used mark.

JSC: Okay, I'm sorry hacks Waldemar, Richard and Justin. I know you had items. I'd encourage you to try to show up where that, that overflow time. Okay. Can we just wait for the note takers to take the queue and A so we can put it in the notes. Sure. Yeah, let me know Robin when done. And thank you everyone for participating in the discussion. I I'm debating on. Yeah, depending on overflow. I may take present this again next plenary because I think this is going to be this. We need to talk about this more.

Discussion continued the day after in an ad-hoc overflow meeting.

Let’s talk about test262 maintenance and contribution

Presenter: Shu-yu Guo (SYG)

SYG: Okay, is me. I have no slides. This is not a proposal. It is a discussion about test 262 and how we should. As delegates. Think about this 262, how we work with test262, so I'm not going to really give the full history of test 262 here. I think folks are better suited for that other folks have more context. I mean, but we I think it's not controversial to say that currently test 262 is extremely important to TC39 and to the JavaScript ecosystem, at large not just as a kind of spec coverage, kind of thing. But as the first line of defense for guaranteeing interoperability in implementations. It is the quickest way to get an interrupt thing Fixed is probably to commit a test 262 test and not to fix the spec. Actually, of course, those things should happen in tandem, but if you just fix the spec without a test 262 test, Unlikely that that might get acted on sooner. So anyway, I think we all have a lot of vested interest in keeping test 262 humming and contributions healthy. So with that, I want to kind of just open the floor to discussion for several questions. So historically, as long as I've been involved in test 262 as an implementer and as a sometimes proposal author, there isn't really too much of a formal workflow for test262. There are like, you kind of have to know a bunch of stuff. Hopefully you have someone Mentor you. Hopefully you are in contact with one of the folks who can commit the test for you and review the test for you and ad hoc, and this ad hoc workflow. I think has worked fine. There's been some points in recent years, where there's been friction there with some staffing changes at bocoup for instance. There was a slight period of time where it was unclear who could review or commit tests. Now as RW mentioned, two days ago, maybe yesterday. We are in a much healthier spot, so a chrome at Google has for the past many years had a contract in place with bocoup to kind of fill in the gaps. Where needed in the service of shipping stage three features. If it's missing test262 tests or the existing test 262 test for proposals, there's spots that are missing that contract kind of filled in gaps and contributed test or review test to, to make sure we could implement and ship things at a reasonable Pace to keep up velocity going forward. has, as you may have read in the reflector about who is withdrawn from that space. So that contract is now in the hands of Igalia and we will continue to kind of find such an effort to fill in the gaps that said, I think we should have a more formal approach for working with test262 and I think we're approaching that now, with the maintainer group that RW mentioned. So, the questions I want to raise for discussion are Are we in support of a more formalized workflow and defining the workflow for how to contribute to test262 who are expected to contribute from test 262? What the, you know, know, more formally articulate, I suppose expectations from proposal authors in the proposal process for how they contribute to tests. To test 262 correctness is a difficult issue when we write tests 262 test for proposals there. It's often before the point where there is any executable implementation, whether that be a battle polyfill or via implementation behind a flag, or what have you, so proposal, authors or sometimes folks at Bocoup and Igalia and account acknowledged in the past are basically just writing tests against the spec and reading the spec and staring at a real hard and trying to write tests, the tests done invariably some those end up being incorrect. Come time. We Implement and we find, we find bugs. Sometimes in the tests, sometimes in the implementations part of the difficulty, there is that It's not always the proposal Champions or the proposal authors who are writing the tests and they are also not historically been in the reviewer loop, I think SHO suggested in a chat earlier that perhaps proposal authors and champions should be the reviewers for test262 contributions. And that's now, that's one idea there. I'm sure we have talked about the possibility of requiring test 262 tests earlier in the process Stage before stage 4. I also want to resurface that topic. So, This is just kind of a free form thing to discuss. You know, how we should think about test 262 beyond somebody else's problem.

BT: The queue is empty. I wonder if it's possible to well LEO has a clarifying question, but after that, I wonder if it's possible to some more concrete question on the table to sort of guide the discussion in a more structured way after LEO.

LEO: People's to suggest things like this as like. who should, how much Champions should be involved and historically, Proposal Champions are always, recommended to be the authors or reviewers of the test and historically, this doesn't happen often and we try. I'm not sure. this is a frequent thing at test262. It's a project that is appreciated. It's important. And I agree with all of this. It's not an easy process as like implementing an engine. It's not an easy thing. not everyone here Can Implement an engine Unfortunately, not everyone here. Can dedicate time to test 262. Therefore, you have people who are sponsored to this work. and I kind of like going to send a because these questions keep coming back and back. I'm not sure. What's the point of this question?

SYG: Okay, I will ask a concrete question then and I would, sorry to put you on the spot. SHO. I believe you're the one who suggested to me that perhaps we should have explicitly designate proposal Champions authors as reviewers. So, one thing we could do is instead of that's the first concrete topic of discussion, instead of merely encouraging. Authors and champions to be in the loop for test262, We have it as entrance criteria to for example, stage 4 currently where, it's not enough that there exists test262 tests, but that the Champions have signed off on them. Otherwise, they cannot advance to stage four or maybe even stage, 3 to get things to get the ball rolling earlier.

RW: I'm excited that SHO independently came that same I think intuitive conclusion. That's actually what we've been doing for years, which is to harass, I would say the proposal Champions into reviewing the tests for their proposals. I mean like nicely, harass them. That is, we made a maintainers have put it in a concerted effort for at least I would say since the like 2016/2017, which is basically, when the proposal document, really. To be the process document was really solidified and was firmly any place. first, we would look, we had hoped that like, full proposal offers with, like, LEO said, would just, you know, write their own tests, but it was that good, but that's fine. because some people love to write tests, some people don't know. What we did do was we made sure to verify with one more one or more of the type of person Champion, Champion, spec author,or an individual, who has expressed interest in a given proposal and has put in a substantial time and effort, but maybe isn't part of the Champions group. But has demonstrated a breadth of knowledge of the given subject area for example Andre bargull, right? right? Your proposal author. What a hell of a test review or author? Test driver. Oftentimes. We will reach out to Subject matter experts. So for example, if somebody wants to write tests for regular Expressions, I will always reach out to MB. I don't want to review a regular expression tests. That's just not available. He is good at that stuff. You could say expert. So one or more people from that sort of General group of officers and champions or deeply invested contributors in that subject, or generally domain experts to sign off. Would I like to see a formalized process for that? Yes, absolutely. Not sure what that looks like, but 100%, I would love to see that become like a requirement. I also picked up on a thing that you mention in there. I think you placed it in the wrong place, but it's okay. Your intention was, right. This is something about having blowing. I think you were actually talking about entrance criteria for stage 4. So never mind you're right. There is like this. An issue that exists and everybody is this a like I know exactly, which is when something becomes stage 3 is the race is to write tests for the future before implementers start turning up the implementation, because would be better for them to have something testing. It's great. And if that particular feature is not a prioritized saying sponsored contributors by the The entity sponsoring it then the well test might not get written, directly exist before implementation starting and you're kind of working backwards now, and it just sucks. Trust me in like the decade almost to, or whatever. I've learned that sucks. But yeah, so it would be cool if there was like a stage two and a half. I've always wanted a stage two and a half where it's basically stage 3 implementations shouldn't even really be allowed to start until there's some kind of test material, but that brings us to this other problem, right? That you also called out which is like oftentimes we start writing these tests and you know, frequently in the past. Like the day after a TC39 meeting is done. We would have a meeting. It's like all right, what things are stage 3? Let's prioritize those. And we start writing tests and frequently, there is no implementation, which is, can be a wild ride, like iterator helpers. I don't think it was actually stage 3 when we start working on that. We're trying again.What? Things like that with With that is where I was really feeling like I wish there was stage 2.5 again, Not sure what that stuff looks like, but these are formal processes that I have personally felt pain the need for in the past, many throughout the entire time. So, so yeah, as far as like having a formal Pipeline and again, I'm going to hop back to the call stack Back to what you were saying. Where I am excited that Sarah came to the same conclusion in the country. Speaks volumes that like the need is their right to have proposal Champions the Champions group. Have some responsibility to signing off on the tests for the thing they are creating.

SYG: Thank you. I yes, enthusiasm for Andre Bargull is shared by all. and I was not so I didn't want to come to this with a change in process already formulated because I sure if there would be any concern or opposition in adding more process specifically for tests, I guess in, before we continue with the queue. At the end of this discussion. I think I would like consensus or not on I guess elevating test 262 status and incorporating it more into the staging process itself to get ahead of Some of the implementation pains that I have felt over many years at different companies.

SYG: Okay, and with that, let's continue with the queue. Next up is LEO

LEO: Yeah, first of all, to connect it to the main point is the main thing. You pointed out. I am supportive today. I am in no way objecting to this main question. I was thinking it always seems like I need to bring some context that test 262 has historically been a thing where people use it and people has a lot of opinions over it and unfortunately, not too many people get involved directly at test262 by many reasons like time available and everything. I'm trying to collect ideas as well because I'm not putting this as a problem like my perspective, my historical experience with many others. Many champions. Is that like some of them get involved in a very healthy way that I actually appreciate some of them are, somehow like not getting too much involved, but appreciative of the work. And there are people unfortunately, that just goes like, ‘I don't care’ with like a massive ‘I don't care’ to the point like where we reported like some tests were ready and they were not different to that person. like regardless as they could ignore them. The work that we did like that, the work that the are people paid for. That's just x 2 is mostly writing tests reviewing test, test. But maintenance is the burden that comes bundled with. Where there is a lot of things here and there that's just a lot of things are Legacy and people would love to change that. and a lot of people like to voice how much we would like to change that test262, especially to make it compatible with an implementation X or Y, but being the support for the maintenance. Means you're going to get this communication from these many people. People who say, it's like we should bring this bundle to test262. We should modify these requirements for test262. We should these requirements to test 262, although, these opinions, they conflict. and the level of conflicts of these opinions are so high, that always like, got to the end where I try to work around these and find a working point, which I believe, I it successful because that's 262 is still works for many of us. but people feel like we are gatekeeping and this maintenance causes a lot of burnout. and it's so, so bad. I just hope people understand to the point, like, when we say that's test262, should improve that should be better on this and some of the time it's things like people have already discussed. I'm glad it's in the Plenary Now, because most of the time it doesn't fit business time to be in the TC39 plenary, but people like to change a lot of things. Unfortunately. We cannot change all of them and we can when we cannot change that, we got to the point who, no matter how we work in good faith. We're like we have some new proposals, new Champions getting involved and say, yeah, should change the whole structure of test262 to fit my test in, This happens. It's not like one person. It happens. This happened in the past and I was always in this spot that I like, it always felt somehow in a spot in to work with this, but I if I really get entertaining seeing how this project makes its own through, like how this project is Well done. I always act in good. Good faith. I know a lot of people recognize that, I know and but the voice of the people who doesn't care about that and they just want their own specific business thing on the project, but cannot understand the total of how many people use tests262 is hard. So bringing a thing like this and SYG. Let me make it clear. It was always a pleasure to work with you. and I'm not putting you in this spot because like you are the person who I always had the pleasure to work with, a lot of other people here as well. But also like this, this is the thing that happens. People cannot see that and it's unfortunate because like when we try to say a thing or not cannot happen, it's because we know I'm pretty sure Igalia is going to face that. I'm not being involved with the project anymore, but I'm pretty sure you Igalia is going to see that. I'm done speaking. Thank you.

SYG: Thank you, LEO. I am. sorry to hear the difficulties You have faced in the past. test 262, being a TC39 project. I think it should be in scope for the code of conduct committee and enforcement of code of conduct violations. If not in the past, certainly going forward. If there's unbecoming behavior in treating the maintainers group.

RW: I think this is that at that event predates, the code of conduct committee, but I guess this specific one predates.

LEO: Yes, but I was in a spot that I couldn't complain about this. I couldn't make this public. As well because it's it's my, yeah.

SYG: Okay. I was not thinking of that kind of problem. It is true that different stakeholders just like in committee, different stakeholders will want different things. Out of test 262 to my constituency are the browser implementers. And as I led with this conversation, I see the main value add, if not the main value add of test262 is kind of the first line of defense for interop. It is quite literally, I think what is responsible the level of interop that we enjoy for JavaScript today, and that will be kind of where I'm coming from for, for what we should optimize for. We're search article for what we should prioritize in test 262, but part of the discussion for kind of elevating test 262 and bring it more into the process is, you know, formalization of the maintainers group is to better Write things down for what the extent of like, what is under the purview of the maintainers group. Maybe some things do need. consensus of committee, but maybe most things don't, in terms of the maintenance of the test suite itself, but in terms of should we what should we what kind of use cases of test262 we should prioritize. I would like that to be brought under Canary discussion. If it involves significant Staffing changes, for example, a success significant engineering involved, it is a it is a TC39 project if we want to completely redo how we maintain the specification text. I imagine. And the editors want to bring that to the committee and not just do it one way or the other. I would like to see something similar for test262.

SHO: Yeah, so I think some of this came up in the back and forth but one of my goals and a vision I have for test262 going forward that I think speaks to some of the concerns people have mentioned. Previously is I think it is highly desirable for us to have a written process for suggesting changes for how we should put things through, for who is being added to the maintainers group and what that means and what rights does are right, Because it's it's clearly a heterogeneous group of people who I think at heart that all want the same thing for test262 at base, which is to serve the stakeholders of tests262. Well. And have it be a useful tool for everybody who's implementing JavaScript, right? Like, I think people agree on things, but when lack clear processes and written down processes, then it means things can start feeling personalized and they don't have to. Like, I actually was not here for the whatever happened previously, so I am blissfully unbiased on my opinions of what happened, but I think that with the correct, sort of understanding of processes and responsibilities that everybody agrees on, Then it's not personal to anybody because it shouldn't be, because it's building a tool and not you know, some it's not like art or something. We're building a really useful tool that RW and LEO and many other people spent years and years and years, making good and useful. And that's good, and useful. And I just think that my goal and my hope for the maintainers meeting which also other people interested in it. Please. Let me know. Like I'm happy to invite people and for us to use that as a structured place to continue these discussions so that we can arrive at a place where how to get involved is clear how to make suggestions is clear, and I think it can feel a little less personal, so that's my first topic and my second topic.

SHO: And one of the questions I do, think really need to address and it's come up in discussion previously, right with SYG is who are the stakeholders for this. Because again, if we want to make decisions on big questions, we need to understand the parameters are making those decisions under. And the question is, right. Who are we serving? And then I think a lot of the other decisions can fall out from there, but these are the kinds of things. I'm hoping we can like talk about and agree on together and sort of move forward with together so that everybody feels like they know what's expected and that their effort is being respected because that's really important, important, too. Thanks.

SYG: Thank you, SHO. yes, I think I agree the stakeholders question is an important one and I hope it will be reflected and Whatever we do right now. Final topic on the queue from SRU.

SRU:: Hi, we wanted to contribute our generated tests that revealed bugs in specifications and JS engines to Test262, but it was not clear how to do that nor whom to ask for a process. Also, we were wondering whether it would be helpful for proposal writers if we can generate an extension of an existing interpreter with a proposal. So that the proposal writer can test their proposal, using their own tests and then check the validity of the proposal and submit the tests to Test262.

SYG: That would be the best thing since sliced bread. If that was possible.

RW: I've heard twice now that about this idea that it's unclear how to add tests to test 262, frankly. I think that that's a question that should be proposed to GitHub. if that is unclear, because GitHub is where the tests are and we rely on github's Tools that they have, you know, in a we're just using a regular public repository for you know, you open pull requests. So if it's if it's unclear how to open a pull request that is Not something we can change the GitHub website. But that's all. that's all I've expected. And With regard to like, what's expected of tests. The contributing document is thorough in the interpreting document, which is useful for off is not geared towards authors. It's actually for anybody who's writing a runner. So consumers, but it is useful for informing test authors in how their tests will be executed. So between the two, you could internalized the information and basically create like a Testing runtime in your mind from the information there and we actually use the contents of the interpreting file is what the version number of tests262 is predicated on as it turns out. So, the only time we bump the diversion number of tests 262, is when there is ever a change in, how tests are expected to be interpreted by consumers. Because consumers, I think this goes to the stakeholders question. Honestly, anyone, any entity that is Consuming test 262. For the purpose for any purposes that, you know, you don't actually have to consume test262 to validate with a JavaScript, runtime fact, we know many use cases that just use it as large blobs of JavaScript that make for great test fixtures. That is a valid use case. Moving on, the directions to those files are actually right on the test uses to repository readme. I would the primary stakeholder The Entity to which tests 262 ultimately answers to is Ecma and I guess TC39 by way of, as test262 is actually part of the technical report. That is part of a set of documents, which I usually remember off the top of my head and can not apologize for that. But all the information is argue about is about the about the technical Point 104. And which is included under the Ecma 414 suite of specifications. So that's our primary. That's the answer to the exact day, when

SYG: I don't think SHO meant stakeholder death since the legal structure here.

RW: I agree that that actually took the words right out of my mouth a dead singer said, That was where I was going next, which is I don't think that that's the kind of stakeholder buy-in by think that primarily we’re talking about implementers. I believe, I've always believed to be the primary. The primary stakeholders in the sense that as consumers of test 262, they have the most on the line or test your 16, being stable, reliable and economical. implementers of JavaScript tools within implementers JavaScript, tools being active. so tools, write it down JavaScript for that includes, includes. Static analysis. Analysis compilers. And, and I think that there's two primary stakeholders with regard to Consumers. I think there is a group of stakeholders that are is important to that are sort of ephemeral or maybe not. I'm thinking in terms of like proposal authors and the spec editors are also stakeholders. It's important that test 262 to actually reflect what the spec authors. And when I say spec authors that also from now on that includes proposal authors, because they're writing spec too. It's the most important thing that test262 to be representative of what's right now. Like from, So, I would say that. you know, a 10,000-foot view. Those are the largest groups. And there are, of course, smaller subsets, and then like smaller sort of Fringe groups there. But those are definitely the larger groups. Frankly, I don't think we have that written down somewhere. There should be a markdown file. That says all of that. It is definitely important. Would be nice to be able to point to that when people are saying. can't we just use mocha. No. you know? Why? because how does that serve these groups and point to document? That would be fantastic. Yeah. Again, I think a lot of this, there's a like, a lot of domain knowledge. knowledge, and I think SHO is right the money that needs to be like pen to paper.

SYG: Okay, ours are yeah. I do want to back up SRU can hear that even for browser engine Engineers. It has the fact that some set of documents do exist has not necessarily eased, the friction of contribution. So there is it. I think the ergonomics of that leaves something to be desired and we can certainly work to improve, okay.

SYG: But we don't need to go into that here. I think in the interested in you,

RW: you brought it up a lot of that fraction. You're talking about, frankly. It has been the ease in which browser engine implementers are allowed to dump whatever things they want into WPT because WPT has an open-door policy, but I think like are locked. I agree that those like frankly there are testing not a lot of browser can run because not all. the browser's even have the right resources to do so, because that's allowed because some engine authors have said and asked that they want a two-way sync. They want their Engineers to be able to just accept whatever do is. Thank you. So I think that this is a good conversation than this point to say, I think a thing like this is actually contentious and is actually like affects all of the consumers of test 262. And the reason why test 262 currently runs for all consumers, the way it does is because there has there's long, been that like a rigid review process. bi-directional sync, eliminates any kind of like guarantee that what you're running is actually has actually been vetted..

SYG: in my experience, many tests have not been adequately reviewed. I disagree with the notion that historically test262 is a very rigidly reviewed. There are certainly large swaths of it for which it is true. But I would not say that as a general statement.

RW: Okay, so either one, either. What I'm hearing is that you're saying during the tenure and which myself LEO and probably was not about.

SYG: Sorry, Rick, this feel like it's getting heated for some reason that I don't understand why, I am not blaming you.

RW:I'm just trying to understand. What you're like, what you're trying to say.

SYG: Well, I'm addressing that. You think that the two way sync, for example, would detract from the quality of the test Suite. While I disagree that, I think it would improve the test and that a test Suite philosophically, I think ought not be a carefully vetted thing whether or not the test. Well, that's that's out too. Like this is this is okay. I don't think this conversation will be particularly helpful for the plenary body what I would want to get out of this discussion is consensus on. Before we do the work of writing things down, formalizing the maintainers group of kind of figuring all that stuff out and, and writing up a process and possibly writing up a PR against the process document to introduce. For example, 2.5, this stage with you. Talk about that explicitly mentions tests before we get to stage three or four before we kind we kind of do that workout. Consensus from the group that that is a desirable thing because it would mean more work delegates, specifically, for proposal authors.

BT: Yeah, and considering that we only have a couple minutes left. I think we should really focus on getting that a couple more items on the queue that I wonder if we should delay those entries for now and focus on what you want to get out of this. From plenary. It's up to you.

SYG: how long for LEO and YSV.think each of your items will take?

YSV: Two seconds.

SYG: Then, let's try to dequeue first. All right, LEO. Please try to keep it brief.

LEO: Yeah, actionable thing, I think they're so the contribution Gap that it mostly in test. 262 is actually how do we create the coverage mapping? This is one of the things like I'm not even trying to get like formalities of test262, but there is no objective. So this is in what is coverage? What needs to be covered by test262. And this process is subjective and it creates a lot of questions who wants to contribute. I think, if we want to talk about mentorship, maintain ownership and improving it. I think we need to improve the process that. I am. I already address some of the things that I like editors. We're here present in things are being Progressive terms of, like we now just had a presentation of some procedural way that we can use to explore coverage. I think we should invest time in that if we aren't going to talk about betterment of maintainership

YSV: So the way that I've seen the goal of test262 as a test Suite is for it to be complete. That is that it will accept any engine that correctly implements what ought to be exposed from the perspective of the spec. That's its goal. And think that that's a pretty worthy goal. So if someone decides to write a version of JavaScript that has the same surface area, and does some other weird stuff that they could use that test suite. My perspective, I have in the past pulled in JSC tests or V8 tests often manually, converting the different test Suite patterns to the spider Monkey one, and we do have a folder called implementation contributed. I think it would be beneficial to the quality of all of the implementations if this folder was synced across major implementers, and this would not impact the underlying goal of the test 262 of being complete.

BT: We are out of time. SYGwould want to bring this back around in 30 seconds.

SYG: Yes, please. I would like consensus on. Let me try to phrase this. I would like to have consensus on one: formalizing the maintainer group of tests 262, who are, who is empowered to maintain test 262, which is review and commit tests. And two: consensus on making changes to our process that involves doing more work to ensure more tests 262 tests and higher quality test 262 test early, in their earlier in process than what we have today, the specifics of which will be worked on than presented at a later at a later meeting is basically, I want consensus. I want to hear concerns and blockers from folks who are objecting to doing more work with respect to test262 in the The Proposal process.

BT: We have exhausted. our time to hear those concerns. And I imagine that the details of the maintainer groups would also be forthcoming. So you're really just looking for blocks.

SYG: I want like, if I'm not doing Work for test62 because I already don't want to. I want to hear that. Now before we go off and do some actual process work here.

BT: Okay, if anyone if anyone has any strong concerns with the notion of a maintainer group, or the notion that we can improve our process, to make test262 better, please raise them now.

[silence]

BT: I don't hear anything. So I think in general, those are good Avenues to go down, although obviously details would be greatly appreciated. Of course.

SYG: Thank you. All. All right, sounds good.

Conclusion/Resolution

• formalizing maintainer group of test262
• consensus on champions doing more work towards test262

Intl.Segmenter v2

Presenter: Frank Tang (FYT)

• proposal
• slides

FYT: Thank you for coming. My name is Frank. Tanya phones, my man and Chinese. And today I'm going to talk to about Intl.Segmenter API version 2 to proposal for stage 2. So the motivation is that we have already a intersect B under API at 142 in stage for a couple months ago. And in this version of to proposal we were at Intl library, Grant analogy to search for high-end agnostic rib, that can handle for figure out how to do a logical linebreak point. Whenever in those contacts, they already have a way measure text with. And so, therefore they can do line layout in those conditions.

FYT: So, the problem statement, for this particular proposal, is that currently segment already support preferring break word break and sentence break. But in particular if you look at the history with web HTML5, we have browser have gone in CSS, which overcomes high-level aspect, right? So you have a tan API CSS JavaScript can have a high level line layout just construction, though, and the div will do the layout for you. But in the last 20 years, HTML5, canvas adding sund support API that you would do a low-level construct. They have fuel tax and scroll tags and to render piece of text on the canvas and also have major tags to measure the width. And so there is a need for those thing and there's there's other cop places like, SVG PDF, or some other condition that charged groups, the handle itself, not in a DOM context lines on the rendering condition that requires some low-level API to support, to figure out where is the opportunity of line break. So they can do that wrapping correctly. I think Richard Gibson naturally mentioned some of the usage here. And also we Find this in a lot of other places like GS P.DF. They do generate PDF file They are try to use him JavaScript. in those contacts. They don't have palm tree. They will generate the line break a PDF and this will be a very good usage for that. Currently. They have some bottle 19, which can only handle western-style routine. But a line break opportunity will help them to figure out how to do this thing. We also have a lot of requests from different places. I think one of the user mention about what webXR, and webgl, and some other 3D engine have that walk. Interesting happened. Was that we doubt that a lot of time and another motivation for doing that is V8 in before the ecma 4 at my for transforming in about 2010 ship of V8 break iterator, which have the word break, preferring break sin has break and also line break. and we really tried to obsolete. I think, but we cannot do so on until we have a standard normal implementation that can bring the parity with that and we can encourage our current user for that to migrate to the new standard API.

FYT: The API shape of why I'm trying to propose here is like this, right? So basic word. You have a segmenter and we just have a new value for the granularity in line and you have passing, for example here Japanese packs and creates a current API that you've used in word break. It will break were but now it will break in the second floor of the library opportunity and caller can calling whatever routine true figured out the with of that in the particular context, usually not in the HTML DOM environment. Because in that kind of environment, you should just use basic CSS. DOM to do that. But in usage, for example, SVG or web ml or, you know canvas that you don't have a DOM tree, you can have to do that kind of thing because we are working a lot of contacts and also there will be need help, additional attribute with line-break style this compare with a CSS back. back. They have three different Line breaks style to support a line break. So this is a basic high level definition have a drafts specs. Can take a look and also have a V8 prototype that can take a look to here. You can click on a link to look at that. So in stage one proposal we have the this draft. I mean, this already State one, but in order to do that, I want to repeat here. Is that one of the things, the issue criteria is to have to think it out potential, cross-cutting And one of the cross-cutting concern, is that a line break opportunity cannot work alone without a text measure, API, and as I mention SVG and canvas both have a magic way to measure the text measure tags. Here. I show the Safari HTML5 canvas guide, which I think the APIs are supported by all browser already by quoting Apple’s documentation here. They have matter text and SVG document documentation. Also show W3C computer text line to measure attacks in SPG, contacts. contacts. So both the line. Packed measurement, a PR are already available in those environment.

FYT: Because this will be added to ECMA402 and I come out for to teaching to we have additional discussion guideline for stage2 advancement, we have to figure out whether it have prior Arts. Where is that difficult to implement userland or whether they have prior art, I want to address here. So first for prior art, one of the prior art is of the a break iterators I mentioned there's a shit about 10 years ago and we have actually about Out one or two and half years ago. I think I start to instrument. What kind of usage are out there. So you can see there are some certain usage of the line break. There are still some a lot of people using it. And here are some examples signs above about those usage. What interesting thing that we see most of them coming from showing the elections for some pie chart or something that based on SVG or convex. Yeah, because And otherwise, they were just using HTML and CSS and DOM to do that. And usually, you can that be if you do with in rendering for some crap that's hard to do within your HTML. They may have some environment have to do this kind of thing and you can look at more example in those pages.

FYT: Another part I think in some other programming environment. You'll see those kind things. APIs is Mac OS have to version of that and the low-level construct this here and Java have this API since MacOS 8 1998. I see you. I see you for Jay and have those things to summon once for more than 20 years. I your Forex, currently the rust. think one of my teammates working on that, too. So there are a lot of Prior Arts. Also, the algorithm also pretty well-known. So a Unicode standard 14 have be published for years. They using the material based on chicks 4051, which also will jointly published. I believe, in 1998. I think this is a 2004 is the second version that they also can Lundy's books 1999, already mention of loud, basic version of the algorithm. And so we also using some reference. Type of defined, by the number W3C CSS, standard Level 3. And so a lot of things, this thing LW H. PR pretty well defined spec. We are referring to that. The second thing 40G to concentration weather is difficult to incoming visualize, right? You've got something very easy to implement in userland. No need to put it here. So one big comparison, is that one of our canvas is working our canvas kit, which is basic that you want. SDK toolkit to from CSS into C++ into JavaScript and they figure out if they pay me to not have to say PID to increment it because they were needed for complex language, how to have tie or Burmese for the dictionaries is pretty big. So such compilation, if we including the whole thing while about what makeup bytes data. Tai,. Korean lat c'mere and a Burmese. And so this is a very difficult to you implement the usual and because a huge need a huge amount of data. The other way to do it is using the V8 break iterator pipeline in Chrome, but used the other way among Chrome. Chromium browser, the problems that will be harder for developer to manage but also costing a lot of page load latency for other non-Chromium browser, which segregate the web, which we don't think it's a good idea. So, it's show there's difficulty to implement in Google and because complex language breaking a lot of data. So here are the third icon is brought appear, whether this is really needed by developer. I show sound the sound hole and you get click on the link on top. Does you see? They are reply. One is from just JS-PDF and they mentioned they need a thing for that. And they mentioned emails or mention the magic packs and get computed text length in the canvas context as an EEG can be used on other. Remember Opera web also? Incheon their design, they mentioned the you can click on that, it will show you their architecture. This will fit a very important need will it's a low-level API, which a high level API cannot fulfill\l. We also have someone from figma which is a webgl, application asking for this particular the asking to us to expose unique online breaking hours at which this particular APIs design for a low-level Construct. And they believe the line-break API in this will eliminate the external library dependency and reduce their bundle size. The bundle size is important. Thing. I mentioned is our previous level usual and so we see would leave the all three criteria for fuel will have prior Arts. Arts. We have difficulty incrementally in userland, and, and have broad appeal.

FYT: During the TC39 by 2021 December meeting when we discuss your vendor stage 1. The question being asked is why not add this functionality to higher level API Like Houdini. This is an interesting question. So I did my homework before I come back ask for stage, two File request, December 16. No one responds. Actually, it is ideal with bring up in November, 2018, when the line granularity was originally, That the ones that you see. I and in November 2018. I think we have some discussion see whether they can bring in the houdini and that time we said we agree. Okay. Well just like, take out the lineup, maybe houdini do you even do that? Unfortunately, after 38 months, not days. Now, 38 weeks ago, thirty three months, the community who need shoulder. No interests, Don't know, concept there. No commitment. There are no research to work on this thing. So that's that's one thing here, but that's not only reason. one of our contributors from Flutter. All This is not a good idea to put that thing into houdinii and And one of the particular reason, this should be in the low level API. This is will be because it will be agnostic to rendering technology, right? And there are a lot of contacts or line breaking usage is not for rendering of for computation Houdini's. Exclusive a CSS feature. So whenever you need it in a non-CSS context, it won't work. So there's a very calm Concrete, answer from someone more working in this space to say why this is not the idea of a Houdini, but we don't stop here, right?

FYT: We have asked another question. Well, if that Houdini, whether they have a better outer place to begin, its I searched around, I feel my homework. Well, we actually find a place that rendering API maybe handle multi textile multiform by diameter line staff, staff, but there's one place called canvas format attacks. attacks. I think always remain composed by. Microsoft, they have a GitHub post there. and interestingly is after no activity after September 2021 and I post a question there. there. There's no response. that one place that could be a solution for canvas, but then we have the looking to whether that will really be the answer for what we intend we intend to propose. So, put down the thing in sound analysis. The First Column is the name of the thing to consider about, the second column is the V2 API, the third Columns of Houdini, the forth Collins canvas form, its text, which I just mention the valve, as you understand the Houdini a canvas format packs are high level API and they have a very particular rendering technology, depending So, one of the difficulty the Intl segment of the V2 API we’re proposing here. Intend to be in low-level API. It's like you have a tire, you can put on the Toyota, I could put on the home that you can put on the machine events, right? But if you're Houdini, or a canvas format, the API their high level constructs, they have a higher dependency. So, one of the difficulties that you put on high level API, it will not be useful for low level constructs in other places in particular as SVG as JS PDF will not be able to address.

FYT: So here I come to propose for stage 2. So let's review what stage 2 is require the purpose of states 2 is to precisely, describe the syntax and semantics using formal specific language and one of Entry criteria have to be have aspects down, and that Parts down, can take a look at the spec text. At least an initial version. Of course, there are some minor things may change and also all the entrance code here for States work with he now the acceptors, signifies that the committee expect the featured should be develop and eventually included in the standard range. So this is the stage 2 requirement. So here and I come to present you're my main presentation and like for that question.

MCM: Hello, I think. I have procedural thoughts and some technical class, but I'll just State the procedural ones first because I think they're more important in the most recent Ecma 402 meeting. I don't believe there was consensus that this should have should be presented at Prestige to Investments. So, We're actually fairly surprised that this is coming up in this meeting at all before. there's any resolution in a ecma204 forward to and there is an open issue on the GitHub repository about the particular venue and layering that this these facilities could be added in. And that issue has many comments, and many of them are recent. And so it's pretty clear that the conversation is still ongoing. and so it is is quite premature to have this proposal to the advanced to stage two because the acceptance signifies of stage 2 says that the committee expects the feature be developed and eventually included in the standard and that is exactly what the discussions are regarding.

FYT: How are you all to a procedural problem to dash in my colleague? He's the chair of TG2.

SFC: Hello, everyone. I think FYT’s work here in advancing this proposal is very worthwhile. I think that he made a very strong case for that, that Ecma 402 and TC39 is the correct body for this proposal. I agree with FYT’s logic and I think FYT presented a very compelling case and the reason that we're presenting this here is because this is the correct venue. If this group still has concerns over that, then that would clearly be a stage one concern, but part of the purpose of having this meeting in this broader group is to get feedback on exactly that problem and get input from more people who are here. I'm aware of MCM’s concerns. And I think that those concerns are valid and I'm hoping that we can have the discussion here with the larger group about this subject. I'm personally quite convinced by FYT’s logic and the case that he made in his presentation. But I also want to get input from everyone else.

FYT: I think the issue I would like to defer to you. Is that a procedural violation to bring something that teach you to didn't feel consensus to hear and I don't think I'm ever claimed that we have consensus and I don't do not believe, there are any process. Documents say, you have to have a consensus know in TG2.

SFC: TG2 to does not have does not have power over stage advancement. This meeting right here is procedurally the stage advancement. Meaning the meeting we had two weeks ago, TG2, was an opportunity to get input from some folks in TG2. I think that Frank has, you know, revised this presentation a bit since that time, so I don't see anything procedurally wrong with having his presentation here.

TAB: Yep, this is slowly falling upon MCM’s from what I could tell from this presentation. There hasn't been any work to address MCM’s concerns. You did instead go through and find it where previous efforts that MCM had cited as attempts to solve. This properly. Hadn't been significantly worked on in particular, the Houdini spec for text layout API. Which was originally on, WE Google were on the hook for that. And so we Google complaining that we Google didn't prioritize a better solution to this and so we should use a less good solution to this. Is it a great look? Ultimately, it's a prioritization problem within the Chrome team and we can solve it within Chrome team. If necessary. I don't think we should go from this hasn't been worked on because the person working on it passed away. We should do this This. Other thing instead is necessarily a jump is wanted to make here.

FYT: I believe the Houdini will not be able to possible to address the issue with endless.

TAB: So that's my next issue and we just jump over into that. I think you are wrong about that. The point of the Houdini text layout API is you give a chunk of markup along with a few constraints, like what width and height, you're laying it out into whatever, whatever other information you need and it pops out a bunch of information about each text fragment giving the width height and the position that it would be positioned at. That does have a slight connection to HTML. You need to give it a fragment of document. It can definitely work with SVG in theory or you can just feed it. Well, like raw text and then position that manually with SVG if you're going in a completely DOM-less environment. Like you're just using NodeJS, I agree. That wouldn't do enough but my argument there is raw text without a DOM is not enough to format text across the world, the, the big problem here is a number of languages are hard to segment. Expensive to segment. They require dictionary support to know where you can split words in half. And so that's an expensive library to ship and having it built-in would be useful at. So, the main argument here, but knowing where to segment things is not nearly enough to actually Implement text layout in an international sense. In the simplest example, if you're mixing English and Hebrew the bidary algorithm will put things in places. You would not expect. and if you just look at segmenting information, you don't get that. You need significantly more information about actual text layout, and all of that is part and parcel of rendering text well, regardless of what your output surface is going to be whether it's going to canvass going to JS-PDF, whatever you need to know positions of text fragments as well as just break points. And that is the precise information that we had planned to offer via the Houdini text layout API, which is not explicitly CSS tied. but which works with it. But is explicitly layout tied and gives you all the necessary information to do text layout. On your own side. If you need by actually running text out as the browser would. Anything less than more it, while it help binary sizes in some cases will still not address the need that you are asking for and that's a problem because break iteration like this is purely a text layout concern, unlike the other iterator types which are semantic in nature and can be used for things other than layout. If we're going to do layout, we should do layout, right. Houdini's. One way to do it. Maybe there's other ways we could do it instead, but just addressing this won't do enough and will be an attractive nuisance for people trying to do internationalize text in the future. If they try to use this, they'll still need to use significant additional work, which requires fairly expert guidance to write, which has already been done by the browser anyway,

FYT: I don't want to point out that when you say you need to buy. I died too complex scripts, support supported rash is correct? The partially not biders algorithm and actually are published for 30 years, and there's already jar screwed Library handle that and I think one the fluttered Mansion also they mentioned they had show that about hop to underline the curl, which they can handle the bidi there. I was the tech lead in Mozilla in 2002 to increment by Dy was held from IBM Israel. So there are open source reference how to do bidi and complex script in Mozilla open source for more than years, years and it's nothing Right? And the bidi algorithm implementation is already there. So, you're right. You need to have a biidi for complex script. Actually are not needed. So here's one example, the left hand side is showing the V8 break iterator showing the this show in the Hebrew and Arabic. And I think the second the fourth line, Fifth Line, the right hand side is showing demonstrate and Safari Mozilla and you can see the Chinese and Japanese cannot be segmented so they have to just go over the edge. So when you say there's a complex screen issue, it is true. If you have to do is acquire frame rate, but not the line break Library internally in the library are reason. it will break that incorrectly the unit. That will not have the complex script issue. I understand your concern. I think that were more tied to with what's are called grapheme cluster breaking but now with language

SFC: Yeah, I'll just be fairly quick speaking as a member of the Google internationalization team. We receive requests very, very often for solving this specific problem of the payloads requirement for a proper line break segmentation, because it does require the dictionary or LSTM data, etc. And it's definitely the biggest chunk of the [text layout] engine. There are other pieces of the layout engine—that is absolutely true—but the piece that is the most problematic for our clients is the segmentation piece.

[call interrupted; waiting for everybody to rejoin]

SFC: So what I was saying is that you know, speaking in my role as a member of the Google internationalization team, this request to reduce payload is something that drives a lot of our efforts here in this body, and the segmentation piece of the text layout stack is the thing that we get the most requested specifically about. And you know, part of the charter and the purpose of ECMA-402 is to bring i18n functionality to the web platform that is difficult for web applications to ship. A lot of the features in ECMA-402, like date formatting and display names are in and of themselves useful to users, but they are building blocks that other users can leverage. A lot of the work that we're doing in Temporal is not in and of itself useful, but it can be used as a building block to build a calendar application. A lot of the things that we do elsewhere in formatting can be building blocks to build user interfaces. I see line segmentation as a building block. I therefore do believe that TC39 is an appropriate venue for this piece of functionality.

SYG: So being very much a non-expert on text shaping, text layout engines, Hearth buds, this kind of thing. The primary argument I have heard from, from FYT case. here. Is that why we would do it here in? Why would why we would standardized a low-level API? In JavaScript would be to enable DOM-less use cases and I am curious of the practitioners in the room. here. Is this a useful API? Basically, I'm trying to get some signal beyond the canvas or the DOM usecase where there's there are differing expert. opinions on, what is the best approach, but for DOMless is to still to level to be useful, or is it useful one major use case?

JHD: I have non-DOM use cases. In general, every single thing anyone wants to do in the browser, has a non browser use case, because server rendering exists, so I want to break lines on the server without having a DOM available. I also want to generate emails, and I want to generate PDFs, all of which require this functionality.

JSC: So text-based, UIs, user interfaces, and I don't mean command just command line user interfaces. I'm talking about, you know, terminal user interfaces thing things that display text on a grid from possibly from a terminal or from it in an emulator or whatever, the kind of things that use, you know, like box drawing characters think like Think like links the web browser think like emacs, vim creating those sorts of creating those sorts of things without and being able to break internationally without a DOM, using only plain text would be one use case. I can think of how though, I've never done it myself personally. I am it's an interest of mine, and I know that it's an interest. It's something that a lot of people do.

USA: Okay, next up. We have BT, who says that "Finding would boundaries comes up a lot for them."No need to talk. There is one final item on the Queue.

SYG: Can I ask a clarifying question about this topic? So I do I hear that. there are use cases for this API in a DOM-less world, so, I to understand from Tab and Miles. What are the For shipping this in a future where the full solution that you want in Houdini or css, or whatever is being worked on. Is it extra binary size sizes? Extra payload data, price to you that we have ship or is there more?

MCM: Yeah, it is. Yes, yes, that's why I was the the biggest concern that we have is, is maintainability, web APIs the forever. We don't want solve the problem in two different ways. Using two different levels of the software stack and maintain them forever, especially when like Todd mentioned one of those ways. I think he said, attractive nuisance won't actually solve the intended, use cases for the authors.

SYG: So specifically, I'm hearing that. However, this is implemented. However, the Intl SEC Mentor V2 is implemented, Houdini will not be able leverage much of what is done here. It'll just be a separate thing. Two separate API as two separate. Maintain maintenance efforts. I think this is I guess the other sort of the point.

MCM: I was actually on the Queue to Mission is relevant here, which is TAB described how Houdini wouldn't require DOM in order to be used the canvas formatted text effort in their goals section. They say their goal is to create an abstraction that allows authors to collect multi-line formatted text into a data model that is independent of the HTML, SVG data model. So that's of that sort of the It's here is that if it sounds like they're the other two solutions would fit, the use cases that are being brought up here. And so there's no, like it's silly to implement two completely separate solutions, solve the same use cases.

SYG: Where do I understand correctly? You're saying Houdini would fit the domalis use. Cases, how would that be used in noted writing CLI stuff

TAB: in theory? There's nothing about the, the like the last planned API that couldn't be extended to just deal with a more abstract data model. Just text in the limit, but we could decorate that in ways that aren't actually HTML elements.

SYG: You just sent a way that Node can actually implement it. It would be possible.

TAB: I am not gonna count on anything. I don't have a strong opinion between any specific one here. But yes, all of these, even if we make sure that using it with HTML is very convenient. It's absolutely on the cards to make sure that it works Beyond HTML.

Okay, so we are well over time for this. there is, there are a few comments on the cube, but I find it difficult to that, that we'd be able to get through those in a tiny amount of time. So, Frank, would you like to ask for consensus? Another possibility would be to have this on some sort of offline call may be incubated call. I would like to request to come either prove or the banks to stage 2. Okay, there's somebody Objective C H2 for a segmenter V2.

MCM: Yes. [blocking]

JHD: I explicitly support, but the objection obviously holds.

USA: Okay, let's have the have a clear statement of the objection and the and the reason behind it so that the Champions can work on that.

MCM: Sure, I have written this up in a GitHub issue. Can I just linked to that issue? Sure.

Conclusion/Resolution

• Consensus not reached for stage 2
• MCM has filed a GitHub issue with their objection

Continuing symbols as weakmap keys

Presenter: Robin Ricard (RRD)

• proposal
• slides

MM:. Yes. Um, so when we talk about it before, I had this rude surprise of a recently discovered security concern discussions offline and especially SYG’s point online before the offline discussions made me realize that I was thinking about the whole issue completely backward. On confining information, our whole approach, which just the sound is to deny, The By the authority to read. channels not try to suppress the writing of covert channels. And in particular to hardened JavaScript already denies access to the WeakRef Constructor the finalization registry default what denies them by default, because being able to sense garbage collection at all being able to observe it already opens a side channel. And with regard to the new WeakRef interaction we that Doubles would provide. It does not threaten the solution that we have and the the property that it does threaten was already long lost on a and that's that's all I feel like I need to say.

YSV: I want to make a clarification about what I said yesterday about SpiderMonkey. It was incorrect. We do garbage collect registered symbols as an optimization. And the way that it was described wasn't quite right. It was described as being garbage collected when the reference to the string is garbage collected, but rather, we count the references to the symbol itself. And if there are no references to it, we garbage collect it. That said we do have concerns - we ultimately do have concerns about using registered symbols as weakmap keys, because it complicates our reachability rules. At the moment using something as a key in a WeakMap or a weak set, or weakref, does not make it reachable. Like that property. Does not make reachable, but if registered symbols Were treated as valid Keys than the spec for all of these would need to be updated to make any key Target reachable. If it is Affordable. So, conversely, the description of whether something is reachable becomes needlessly complex. Registered symbols are reachable by the, by the usual rules. But if they are used as key Target in a WeakMap, or any of the weak data structures, yeah, so they will also be reachable by these rules As well as but the normal rules. So again, this is specific to SpiderMonkey because we are garbage collecting these registered symbols, but it may be interesting for others to reflect on. So there's a weird period of time after something's been removed as a weakref Target, but the JavaScript hasn't run to completion or like, you know, the micro tasks queue hasn't emptied or whatever. It probably won't be a problem for implementations, but it feels like it's asking for trouble in semantics if an implementation wanted to be more precise in collecting registered symbols. And that's it.

SYG: I just want to +1 that there is a bit of implementation complexity for allowing registered symbols. Because the weak collection marking in all engines is one of the most complicated parts of the GC it's ephemerons and it's fixed points and it's harder to kind of make concurrently with mutator and make parallel. So complicating that is undesirable. It's I wouldn't say it's impossible or hard blocker, but it is definitely undesirable.

RRD: Okay, I guess we'd like to have maybe more assertive stance on this. Would anyone feel like it would be that discussion with anyone would feel like it would be a blocker if we were to accept registered symbols as WeakMap keys. Okay. Yeah, that might actually address it.

WH: Yes. Allowing registered symbols WeakMap keys would be a blocker.

YSV: And I guess WH, you're referencing the for jables aspect of that. Would you be able to describe that a bit more? Registered symbols are value types. Non-registered symbols are identity types. WeakMap keys don't have any value types at the moment. We should not add value types.

RBU: Yeah. I just wanted to since the implementers like the SYG & YSV are on the call talking about it. I wanted to see y'all hadn't comments on implementation, collects the regarding known symbols or if this changes anything, or if you have any real opinion on this record with regard to the engines.

YSV: I can just say, since I answered wrongly about this with regards to registered symbols. I would like to check with my GC team before. Answering that question.

RBU: Okay. Okay.

SYG: For V8, for well known symbols, I think are exactly like Object.prototype. In fact, they are I think in the read-only space and are shared by everything in a process, if the read-only space is shared. In particular, I remain confused about an example Mark brought up last time about you can kind of get a realm, get a well-known symbol out of it and then like destroy the realm and then recreate the realm, I'm not sure how that makes it like registered symbols because the only way to observe a registered symbols going away and having all strong references to it going away is if no Realms exist, but if no Realms exist anymore, there is no js running and you cannot observe anything. So from my point of view, there will always be at least one strong reference to a well-known symbol and it just basically never dies anyway. So it'll be like adding another thing that never dies. There are things that also never dies, so it's not the same problem as registered symbols and other things that could be re-materialized with the same things that don't have identity. It's not the same to me.

WH: Yeah, I would summarize that as I'm not interested in garbage collecting well-known symbols. Those always exist. But I am interested in allowing implementations to garbage-collect registered symbols.

MM: Yeah, I'd like to respond to what Shu just said. Object dot Prototype is not shared across the agent. It's only it's only per realm. Within an agent an entire realm could get garbage collected even if it's object prototype were in the weak map. Key of some weak map from another realm, which is certainly quite a possible scenario. With regard to SYG's conclusion, I agree, a perfectly reasonable implementation of well-known symbols is to just allocate them statically so they exist once for the entire agent and by doing that, in some sense, the garbage collection question does not come up for them, for those implementations. Nevertheless, if we're going to not support registered symbols my preference would be to not support well-known symbols in the same breath because the rationale is the semantic distinction of forgeability, of whether this is something that can be recreated just starting from a fresh realm. But I'm not going to block on that either way. And even with the main question, I'm not blocking on it either way.

SYG: Yeah, also I want to be clear, I also don't care either way if well known symbols are included in the set to be allowed or disallowed.

WH: I also don't care if well-known symbols are included or not.

YSV: Same, but first I'm going to check.

RRD: Yeah, this is this is great. Actually, I was going to say I'm I'm happy to discuss that specific point between next meeting. You because we might actually want to do some research. It's kind of a new topic. The main topic that we really want to find a decision on right now is deciding whether we should allow registered symbols or not in weak map keys. And so yesterday we had JHD expressing the opinion that it would block if we were going to not allow them and And I heard your opinion today from Waldemar that he would block if we would allow them. So right now we're in situation of deadlock and I would like to use the rest of that time block to get that out if possible. Thank you.

MAH: While well known symbols are none. configurable properties of the symbol Global. It's very well possible to remove the symbol Global or with something else and replace it with something else. Which means in your current realm, the well. Known symbols will not exist. And the only way you would be able to get it is by creating a new realm. So if you have the ability of creating a new realm, the risk for well-known symbols that while they're currently non reachable in your current realm, if you create a new realm, you will get the same value again. That is the point of them being like registered symbols in the sense that they can be recreated out of a capability that is a global API. In this case, Shadow realm in the future or host API for ice cream store.

YSV: I want to speak to the block that JHD proposed and I want to say why I believe that it should be strongly reconsidered. The block is based off of the concept of consistency between typeof result and consistency has a use and a place. Programming language design insofar as it, improves the learnability of a language and And it improves how intuitive it is to use the language. We are currently discussing a highly advanced feature that is unlikely to be used by many developers, especially in a non-wrapped Library format. In addition, reviewing the uses of symbol dot for I found that doing a analysis of the Mozilla code base. The only places where we had symbol.for referenced were in Babel, which was copied in several places in the code base. And this was the Babel enums type thing that they have that we talked about yesterday. The other place was in the Babel parser. This was about - the total number of instances of Symbol.for a registered symbols was 293. Most these were these two libraries and the rest was made up the entirety of the use. And the rest was taken up by test 262 tests. I did the same search in searchfox which gives high accuracy about what we're searching. The same search resulted in significantly, more independent cases for using symbols just as local symbols. That was over a thousand cases. I didn't do the full grep of the code base yet. in addition, I did the same search over GitHub and we have about 180K instances of Symbol.for registered symbols. Most of them are copies of the react Library. There are several references to Babel and a few unique cases this to identify. What a local symbol count would be for GitHub is much more difficult to do due to their search being much more vague. So, based off of this data. I consider this to be an advanced feature and I consider symbol.for to be an advanced feature. I don't consider consistency to be a good argument here because I don't think that learnability applies in In this case on the basis of intuition. This is something that people would look up the documentation for, we're talking about experts.

SYG: Yes, specifically. The typeof consistency versus - I think we're talking about is forgeability or rematerializability. Consistency is going to be the affordability consistency. I think is more important. is a deeper semantic consistency, rather than typeof. And MAH, I think the a confirmed in chat, he was the one who brought it up yesterday. This distinction is something that we will be reckoning with regardless of this proposal by records and tuples. containing such symbols so So that this is like unless you, you know, unless this position also extends to blocking records and tuples. I think it is not really tenable to, to hold to any kind of typeof consistency here.

JHD: Related to YSV's comment regarding usage, search on GitHub is tricky and searching codebases can easily get narrow perspectives. My experience is that it's often used in polyfills. Node core uses registered Symbols for example for util.inspect, the protocol is a registered Symbol. All the browser polyfills for node core modules that almost every bundler grabs by default will use a registered Symbol for that as well. I also have a library that's used heavily on airbnb.com that’s intended to mitigate bundle splitting issues that uses attaches registered Symbols as properties on the global object to cache things across bundles. I don't think it really changes the discussion; I just wanted to point out there's lots of other examples beyond the ones you cited. But I agree it's a niche feature more often used by library authors than by the average developer.

JHD: My next item was I just want to make sure for the notes and for myself - It sounds like the three options are either, “no progress”, “all symbols are allowed”, or “only unregistered symbols are allowed”, meaning a well-known symbol and a unique symbol are both unregistered. Does that match everyone's understanding of the three paths forward here? Separate from blocks.

WH: A lot of us don't care between the options that were listed on the poll of allowing only unregistered symbols or only symbols which are both unregistered and not well-known. We haven't had that discussion between those two fully, so some people here may care. I'm not one of them, the key part for me is that registered symbols are not allowed as keys.

MM: I will state that I do care. I care a lot about the well known symbols. I'm just not blocking on the question. but it's definitely. It's definitely a substantive issue to me

JHD: and your preference Mark?

MM: The well-known symbols are like registered symbols, because they're forgeable by creating a new realm And and when Once the predicate that Matthew came up with that Shu, just reference once the predicate exists. I would also include well-known symbols on the, for gerbil side of that. Product. So in anticipation of how that predicate should will, I think this decision should be consistent with how, how we expect the predicate to work. But I'm not blocking.

YSV: I can also say what I think here. The strongest opinion I have is that this proposal is more useful in the language without registered symbols, then maintaining the rule that symbols here must be treated as a coherent block. And I also believe that the comment about consistency for around Portables is a really interesting approach to take care of because this is another way that we can consider consistency. I would say that this is outside of the consistency for learnability. It is rather a consistency in terms of mechanism. And I think that that's much more useful. And I wanted to say in response to the topic that you had, originally up here, the of registered symbols, as mentioned. It's in a number of Libraries, it doesn't necessarily translate to the requirement that registered symbols exist on WeakMap keys. And in addition when we make something in error, that is always a space that the spec can expand into. We can never take that back, however.

JHD: Yeah, those are all true. And I think the use case that would translate would be one where somebody is currently using a WeakMap or a Map based on the type of the input, but here's not tons of those examples we’ve seen. I don't think in the next minute I'm going to be able to process everything from this week and reconsider my opinion. My suggestion and hope is that we pursue adding an explicit predicate that has the semantics of “can this thing go in a weak place”, whatever you want to call it, that matches the current semantics for that and get that shipped as soon as possible, so that whatever the answer is to this question of how should we change those semantics that that consumers won't have to care because they'll already be using a predicate that can evolve along with that.

SYG: I think there's a problem with that plan though, right? For symbols. We can't give the the answer as it is today and then change it.

JHD: Why not?

SYG: Because of compat risk. I'm not going to ship something that doesn't throw today and then change for false to true.

JHD: its semantics that would guarantee that if this thing returns true, it won't throw if you put it in a WeakMap. Why wouldn't it be web-compat?

SYG: Because you're changing a false to true you're changing an error to non-error,

JHD: Aren't you doing both?

SYG: Well, yeah, but it's the false to True is the one that would be web breaking. I guess you to go down a different path in your code, right? It would suddenly change the code that you shipped. It will take a different path right?

JHD: So that's what I would like to hear more from you two, or anyone else about. Can you contrive me some code, that is reasonable/likely to exist, that would use the predicate that would actually break? The use case I’m envisioning is if you currently pass a Symbol it goes into the strong Map instead of the WeakMap. And with this change, it would start going into the WeakMap and there'd be no difference because all of the logic would be using this predicate for the correct path.

MM: Oonce the predicate exists people will put will make other logic conditional. You can't provide people a true/false predicate and assume that, you know, all the uses that people will make it.

NRO: So be ready to get will be the same as a custom function, which is just a try/catch around a weakmap and using that package to take different branches. For example, you could try putting in the map. Having the predicate has the same effect, it changes the branch in the same way.

RBU: Yeah, I definitely agree with the sentiment around the credit guy. I think everyone on the plenary, especially this week agrees that the predicate will be useful regardless of what position is proposals, set My concern is that lands in, I guess. I don't necessarily think that the predicates - like, regardless of the concerns with web compat that Shu and Mark are laying out. I don't think that shipping a predicate first really does anything in terms of advancing our choice for us, because the predicate values won't inform us as to which way we should go. It's just that shipping this it will just exist and then they'll change values later for no reason. I think that if we're making this choice like like Yulia mentioned to like provide this little consistency in terms of forgeability, which is really what this product does, then answering that question and providing the predicate seems like something you'd do in a proposal, not like provide a predicate that does nothing and then update it.

MAH: I'm also surprised by the strong push against changing the The result from false true of the predicates because that would have to be the case for new types that we add such as records and tuples in the future. So well, I guess they wouldn't exist today, so maybe not but if it's completely tied to, it would be the equivalent of Try catch, which is actually hard to write correctly without having weird leakage in Savannah. I don't see it as being a problem from changing from false to true for an existing value. It's definitely please trust us. It is is definitely a problem. People will depend on it and weird ways and And you're asking the product people basically the browser's take a risk and to see if we want to change it in the future that you will not break and history has taught us that it will break in weird ways. Ways and we don't want to take that risk? It is not 100 percent chance. it'll break.

JHD: Doesn't that already apply to anything that's a non error or that currently throws an error? Because someone can use try/catch in a weird way and turn that into a boolean.

MM: It absolutely might apply. It's a question of probabilities TC39 every time we change the language, do something for pretty much every time you change the language. We do something that it is possible that were breaking a Program. And we've learned, and we've made many changes and we made many changes to which there was quite a risk and for a few them that we had to back out because we actually broke something where the broken things couldn't be repaired and and there was no predicting which ones specifically those were, but I would say that long experience on the committee and seeing which ones we got away with and which ones do Be done, didn't you? Never know for sure. You're going to get away with one, but some of them are good bets. And I would that a predicate returning true or false, smells like a bad bet. The error turning into a non error, smells like a good bet. And that's that's just a intuitive sense that I'm claiming is backed by experienced since 2007, but certainly don't have statistics.

ACE: It's just the sides of my thing that we the champion group wasn't planning on shipping the predicate as a separate proposal there. So it wasn't an idea, potentially, it could be but we don't see the value in being shipped sooner. We're hoping it would make sense for usage of that API to become available when this new ability also becomes available. We see the Yeah, so don't don't just say.

YSV: Yeah. oops, yes, but I think you can do that after you the okay. Yeah, let's give you your first and I can I can finish very quickly just to support your point. The higher-order bid. Is that this? Help us make the decision that we need to make so we should make that with the decision about this proposal.

RRD: As far as far as I'm seeing things right now. are still being blocked because we still do not know if our champion group should go towards allowing or not this specific kinds of symbol whatever they are registered or known symbols, or Any other kind of symbol we would like to before the next meeting, if possible an idea of getting out of this double block, which is on one side. We want to allow all symbols and on the other side we want to restrict symbols. Would that be possible or do we need to organize external meetings or anything like this?

JHD: It sounded like the question is, what can we do to resolve the double block? my response is, at minimum “time”, and potentially also some sort of offline discussion or incubator call?

SYG: Thanks.

RBU: Would you be interested by the way, Shu in joining such a call?

SYG: Absolutely. As long as I don’t have to facilitate because I have no time.

RBU: Yeah, we will organize it. Thank you to you both. We will contact you.

Conclusion/Resolution

• WH expresses blocking objection to allowing registered symbols
• MM expresses non-blocking objection to allowing well-known symbols
• JHD does not immediately rescind previously expressed blocking objection to not allowing registered symbols
• Call with interested parties to happen in the future to be organized by someone other than SYG

Incubator call scheduling

Presenter: Shu-Yu Guo (SYG)

Talking of calls and facilitation Shu. Would you like to talk about incubation?

SYG: I would, and sad news is no cause have been run since last meeting because of holidays and busyness and short in between meeting time. So I'm not going to call for anything. There is an existing Charter that has not been drained. So I'm just going to keep that and again, have a call for So taters between this meeting and the next, which will be a longer a longer break, so we should have more time to run to class. Please reach out to me or start an issue and ping me or something if you're interested in facilitating, so we have nothing on the schedule except what was already there.