├── README.md ├── agendas ├── 2024 │ ├── 2024-06-26.md │ ├── 2024-08-07.md │ ├── 2024-08-28.md │ ├── 2024-09-25.md │ └── 2024-10-30.md └── 2025 │ ├── 2025-01-29.md │ ├── 2025-03-26.md │ └── 2025-04-30.md ├── meetings ├── 2024-03-27.md ├── 2024-04-24.md ├── 2024-05-29.md ├── 2024-06-26.md ├── 2024-08-07.md └── 2024-08-28.md └── workshops ├── 2024 ├── 102.md └── 104.md └── 2025 ├── 106.md └── 108.md /README.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5: Experiments in programming language standardization 2 | 3 | This repository contains documents, agendas, and notes for the [ECMAScript - Research Task Group (TC39-TG5)](https://ecma-international.org/task-groups/tc39-tg5/). 4 | 5 | See [Scope](#scope) for our mandate. 6 | 7 | ## Agenda 8 | 9 | To be posted in `/agendas` 10 | 11 | ## Notes 12 | 13 | To be posted in `/meetings` 14 | 15 | ## Meetings 16 | 17 | Meetings occur the last Wednesday of the month and appear on the [TC39 private calendar](https://github.com/tc39/Reflector#tc39-private-calendar). 18 | 19 | Meeting link: https://mozilla.zoom.us/j/91426322794?pwd=VmsvdS96c281OE41TENMM0ZUUnN4dz09 20 | 21 | **Last Wednesday of Every Month** 22 | 23 | | | | 24 | | -----------: | --------------- | 25 | | US / Pacific | 07:00 Wednesday | 26 | | US / Central | 09:00 Wednesday | 27 | | US / Eastern | 10:00 Wednesday | 28 | | CET | 16:00 Wednesday | 29 | | China | 22:00 Wednesday | 30 | | Seoul | 23:00 Wednesday | 31 | | Tokyo | 23:00 Wednesday | 32 | 33 | 34 | ## Folks 35 | 36 | - Convenors 37 | - [Mikhail Barash](https://github.com/mikbar-uib) 38 | - [Yulia Startsev](https://github.com/codehag) 39 | - Members 40 | - [Jesse Alama](https://github.com/jessealama) 41 | - [Chris de Almeida](https://github.com/ctcpip) 42 | - [Michael Dyck](https://github.com/jmdyck) 43 | - [Michael Ficarra](https://github.com/michaelficarra) 44 | - [Nicolò Ribaudo](https://github.com/nicolo-ribaudo) 45 | - [Jack Works](https://github.com/Jack-Works) 46 | 47 | ## Scope 48 | 49 | To provide a forum for the discussion, development and dissemination of research work on the standardization of ECMAScript® (the JavaScript™ programming language) and related technologies. 50 | 51 | ### Programme of work 52 | 53 | 1. To summarize and present ongoing research work from the academic community on JavaScript™ and adjacent technologies. 54 | 1. To investigate and discuss state-of-the-art approaches to aid the development of TC39 proposals (drawing from areas such as: formalisms, programming language theory, human computer interaction, social science). 55 | 1. To produce documentation on best practices from research work to ECMAScript® standardization. 56 | 1. To produce and present tools and technologies to aid in the understanding and design of standards for ECMAScript® and adjacent technologies. 57 | 1. To continue and broaden the work, in addition to ECMAScript®, with a general investigation of programming languages standardization. 58 | 1. To establish and maintain liaison with other Ecma TCs and other standardization bodies as appropriate to facilitate and promulgate the work of the TG, including dissemination in academic and industrial publishing venues. 59 | 60 | -------------------------------------------------------------------------------- /agendas/2024/2024-06-26.md: -------------------------------------------------------------------------------- 1 | # 4th Meeting of TC39-TG5 - 2024-06-26 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/91426322794?pwd=VmsvdS96c281OE41TENMM0ZUUnN4dz09 5 | - **Date:** Wednesday, June 26th, 2024 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Central | 09:00 Wednesday | 12 | | US / Eastern | 10:00 Wednesday | 13 | | CET | 16:00 Wednesday | 14 | | China | 22:00 Wednesday | 15 | | Seoul | 23:00 Wednesday | 16 | | Tokyo | 23:00 Wednesday | 17 | 18 | 19 | 20 | ## Agenda 21 | |Topic|Presenter(s)| 22 | |-----|------------| 23 | Editors' work on refining the formalism of the spec|Michael Ficarra (MF)| 24 | -------------------------------------------------------------------------------- /agendas/2024/2024-08-07.md: -------------------------------------------------------------------------------- 1 | # 5th Meeting of TC39-TG5 - 2024-08-07 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, August 7th, 2024 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Central | 09:00 Wednesday | 12 | | US / Eastern | 10:00 Wednesday | 13 | | CET | 16:00 Wednesday | 14 | | China | 22:00 Wednesday | 15 | | Seoul | 23:00 Wednesday | 16 | | Tokyo | 23:00 Wednesday | 17 | 18 | 19 | 20 | ## Agenda 21 | |Topic|Presenter(s)| 22 | |-----|------------| 23 | |UiB's work on PL standardization|Mikhail Barash (MBH)| 24 | |[issue 4](https://github.com/tc39/tg5/issues/4)|Juho Vepsäläinen, Istvan Sebestyen (IS), Mikhail Barash (MBH)| 25 | |a study on MessageFormat 2.0 ([issue 3](https://github.com/tc39/tg5/issues/3))|Michael Coblenz| 26 | -------------------------------------------------------------------------------- /agendas/2024/2024-08-28.md: -------------------------------------------------------------------------------- 1 | # 6th Meeting of TC39-TG5 - 2024-08-28 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, August 28th, 2024 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Central | 09:00 Wednesday | 12 | | US / Eastern | 10:00 Wednesday | 13 | | CET | 16:00 Wednesday | 14 | | China | 22:00 Wednesday | 15 | | Seoul | 23:00 Wednesday | 16 | | Tokyo | 23:00 Wednesday | 17 | 18 | 19 | 20 | ## Agenda 21 | |Topic|Presenter(s)| 22 | |-----|------------| 23 | |A project to implement a Proposal Management Tool ([slides](https://docs.google.com/presentation/d/1ph2O4TMr0hjaYQTFLNEaxrlPLQv8IEFUktjtWLryi5s/edit?usp=sharing))|Mikhail Barash (MBH)| 24 | |[TPAC (W3C annual conference)](https://www.w3.org/events/tpac/2024/)|Aki Rose Braun (AKI)| 25 | -------------------------------------------------------------------------------- /agendas/2024/2024-09-25.md: -------------------------------------------------------------------------------- 1 | # 7th Meeting of TC39-TG5 - 2024-09-25 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, September 25th, 2024 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Central | 09:00 Wednesday | 12 | | US / Eastern | 10:00 Wednesday | 13 | | CET | 16:00 Wednesday | 14 | | China | 22:00 Wednesday | 15 | | Seoul | 23:00 Wednesday | 16 | | Tokyo | 23:00 Wednesday | 17 | 18 | 19 | 20 | ## Agenda 21 | |Topic|Presenter(s)| 22 | |-----|------------| 23 | |[issue 4](https://github.com/tc39/tg5/issues/4)|Istvan Sebestyen (IS), Juho Vepsäläinen| 24 | |update on the MessageFormat study ([issue 3](https://github.com/tc39/tg5/issues/3)) |Michael Coblenz| 25 | -------------------------------------------------------------------------------- /agendas/2024/2024-10-30.md: -------------------------------------------------------------------------------- 1 | # 8th Meeting of TC39-TG5 - 2024-10-30 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, October 30th, 2024 6 | - **Time:** _(please note the unsual meeting times due to the fact that the U.S. and Europe switch from the Daylight Saving Time on different dates, namely October 27th and November 3rd)_ 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | **(!)** **08**:00 Wednesday | 11 | | US / Central | **(!)** **10**:00 Wednesday | 12 | | US / Eastern | **(!)** **11**:00 Wednesday | 13 | | CET | 16:00 Wednesday | 14 | | China | **(!)** **23**:00 Wednesday | 15 | | Seoul | **(!)** **00**:00 Thursday | 16 | | Tokyo | **(!)** **00**:00 Thursday | 17 | 18 | 19 | 20 | ## Agenda 21 | |Topic|Presenter(s)| 22 | |-----|------------| 23 | |Implementing structural search & replace for showcasing ECMAScript proposals ([text](https://bora.uib.no/bora-xmlui/bitstream/handle/11250/3147687/50753831.pdf?sequence=1&isAllowed=y))|Rolf Martin Glomsrud| 24 | |Update on the MessageFormat study ([issue 3](https://github.com/tc39/tg5/issues/3)): the draft of the task design for the user study ([slides](https://docs.google.com/presentation/d/1BIjtIABOumWxh7CPNWT46HwMnYXsJ23GcCcR0LpXLwg/edit?usp=sharing))|Shun Kashiwa, Michael Coblenz| 25 | -------------------------------------------------------------------------------- /agendas/2025/2025-01-29.md: -------------------------------------------------------------------------------- 1 | # 9th Meeting of TC39-TG5 - 2025-01-29 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, January 29th, 2025 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Mountain | 08:00 Wednesday | 12 | | US / Central | 09:00 Wednesday | 13 | | US / Eastern | 10:00 Wednesday | 14 | | CET | 16:00 Wednesday | 15 | | China | 23:00 Wednesday | 16 | | Seoul | 00:00 Thursday | 17 | | Tokyo | 00:00 Thursday | 18 | 19 | 20 | 21 | ## Agenda 22 | |Topic|Presenter(s)| 23 | |-----|------------| 24 | |An Interactive Decision-Making Framework for Programming Language Design|Philipp Riemer (University of Leipzig)| 25 | |Housekeeping|Yulia Startsev, Mikhail Barash| 26 | 27 | ## Abstracts 28 | 29 | ### An Interactive Decision-Making Framework for Programming Language Design 30 | 31 | When proposing changes to programming languages, keeping track of all decisions and concerns related to 32 | them can become a difficult task. This is especially true for more established languages and larger proposals. 33 | We developed a method for expressing design alternatives and their corresponding concerns: a tailored domain-specific 34 | language allows visualizing and experimenting with designs in an interactive manner. To build on this, we introduced an 35 | automated method for decision-making based on severity assignments for all concerns given by the user. This was achieved by 36 | translating the model into a binary linear programming problem and solving it with the SCIP optimizer. As a case study, we 37 | used our toolset to investigate the design space of one of the ECMAScript language proposals. 38 | -------------------------------------------------------------------------------- /agendas/2025/2025-03-26.md: -------------------------------------------------------------------------------- 1 | # 10th Meeting of TC39-TG5 - 2025-03-26 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, March 26th, 2025 6 | - **Time:** 7 | 8 | | | | 9 | | -----------: | --------------- | 10 | | US / Pacific | 08:00 Wednesday | 11 | | US / Mountain | 09:00 Wednesday | 12 | | US / Central | 10:00 Wednesday | 13 | | US / Eastern | 11:00 Wednesday | 14 | | CET | 16:00 Wednesday | 15 | | China | 23:00 Wednesday | 16 | | Seoul | 00:00 Thursday | 17 | | Tokyo | 00:00 Thursday | 18 | 19 | 20 | 21 | ## Agenda 22 | |Topic|Presenter(s)| 23 | |-----|------------| 24 | |Categories of language evolution|Anya Bagge (University of Bergen)| 25 | 26 | -------------------------------------------------------------------------------- /agendas/2025/2025-04-30.md: -------------------------------------------------------------------------------- 1 | # 11th Meeting of TC39-TG5 - 2025-04-30 2 | 3 | ## Details 4 | - **Meeting link:** https://mozilla.zoom.us/j/93671073041?pwd=3IeRE5anlzEVVWK0GbmIM3P2cxTrow.1 5 | - **Date:** Wednesday, April 30th, 2025 6 | - **Time:** [overview](https://www.timeanddate.com/worldclock/converter.html?iso=20250430T140000&p1=tz_pt&p2=tz_mt&p3=tz_ct&p4=tz_et&p5=tz_cest&p6=tz_cst-china&p7=tz_kst&p8=tz_jst) 7 | 8 | | | | 9 | | ------------- | --------------- | 10 | | US / Pacific | 07:00 Wednesday | 11 | | US / Mountain | 08:00 Wednesday | 12 | | US / Central | 09:00 Wednesday | 13 | | US / Eastern | 10:00 Wednesday | 14 | | CET | 16:00 Wednesday | 15 | | China | 22:00 Wednesday | 16 | | Seoul | 23:00 Wednesday | 17 | | Tokyo | 23:00 Wednesday | 18 | 19 | 20 | 21 | ## Agenda 22 | |Topic|Presenter(s)| 23 | |-----|------------| 24 | |Categorizing TC39 Proposals & Observations from Proposal Statistics ([slides](https://github.com/bldl/js-proposals/blob/main/Data%20Analysis/Presentation/tc39%20proposals%20observations.pdf))|Kai Waløen, Mikhail Barash (University of Bergen)| 25 | 26 | ## Abstracts 27 | 28 | ### Categorizing TC39 Proposals & Observations from Proposal Statistics 29 | 30 | We analyzed 257 proposals by TC39 during the period 2014-2025. We propose a classification system consisting of seven categories: 31 | _API proposal_, _Syntactic proposal_, _Semantic proposal_, _Syntactic + Semantic_, _Syntactic + API_, _Semantic + API_, _Syntactic + Semantic + API_. 32 | In addition, we present statistical insights into the proposal process, including metrics such as speed of evolution, and evolution 33 | trends across topics and categories. 34 | 35 | Project webpage: https://js-proposals.vercel.app/ 36 | 37 | GitHub repository: https://github.com/bldl/js-proposals 38 | -------------------------------------------------------------------------------- /meetings/2024-03-27.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-1 - 2024-03-27 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ------------ | 6 | | Mikhail Barash | MBH | UiB | 7 | | Yulia Startsev | YSV | Mozilla | 8 | | Michael Ficarra | MF | F5 | 9 | | Jack Works | JWK | Sujitech | 10 | | Nicolò Ribaudo | NRO | Igalia | 11 | | Jesse Alama | JMN | Igalia | 12 | | Chris de Almeida | CDA | IBM | 13 | | Michael Dyck | | | 14 | 15 | ## Meeting: 16 | 17 | 1. Intro (slides) 18 | 1. Areas of investigation (slides) 19 | 1. Discussion 20 | 1. MF: very interested in executable specifications and what makes that easy/hard 21 | 1. [MF] on customisability: the editor group has discussed how we could really use different views of the same algorithm for different readers (implementers vs programmers), but it's a tricky problem 22 | 1. We could have an implementers mechanics view (for example for generators) 23 | 1. [YS] We had some discussion with Istvan regarding Using AI to assist in standards document navigation 24 | 1. [MF & MB] Generating Natural language for specification text / summaries in natural language 25 | 1. [in chat] Tools for Ecmarkup would be nice 26 | 1. [MF] We’ve spent a lot of time in the editor group refining the formalism for the specification. Can summarize the concepts that we’ve discussed. 27 | 28 | 1. Charter (ad hoc discussion) 29 | 1. [MF] what is the status on that? 30 | 1. We have a scope and program of work. Looks like we are most of the way there. We just need a description of how we are working together. 31 | 1. TODO: Mikhail will do this. MF will help / review. 32 | 1. Responsible Conduct of Research (slides) 33 | 1. Discussion 34 | 1. [YS & MF] Should we only run studies with universities? Universities do have frameworks for maintaining metainformation on studies, reviewing (incl. ethical review, bias) and approving them. 35 | 1. [MF] Not all studies are about proposals. 36 | 1. [JMN] Support for universities to handle studies. 37 | 1. [YS] Would be good to collect the work done within / related to TG5, even if TG5 itself doesn’t register the studies. 38 | 1. TG5 repo 39 | 1. Matrix room, GitHub Reflector for TG5 40 | 1. Yulia will start these. (done) 41 | 42 | -------------------------------------------------------------------------------- /meetings/2024-04-24.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-2 2024-04-24 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ------------ | 6 | | Mikhail Barash | MBH | UiB | 7 | | Jack Works | JWK | Sujitech | 8 | | Istvan Sebestyen | IS | Ecma | 9 | 10 | ## Meeting: 11 | 12 | * Intro (The meeting is a mirroring of the TG5-1 meeting) 13 | * Areas of investigation 14 | * Discussion: 15 | * [IS] is very interested in AI-based tools in standardization. Documentation is important for Ecma. IS talked about an experiment in transcribing TC54 meetings from recorded videos and using an LLM to summarize. Should TC39 try using a similar approach and then make a decision on its feasibility and applicability? 16 | * [IS] There is a “competition” between SDOs and one of the factors is: which of the SDOs will be the first one to successfully adopt AI-based tools. Ecma is in a good position as a testbed, especially in the ICT standardization. TG5 is a good mechanism to try out new tools. 17 | * [IS & MBH] Using AI-based tools to summarize a standard. 18 | * [MBH] A group of University of Bergen’s students has been exploring implementation of a tool to search TC39 Meeting Notes (using LLMs). Example of a feature: summarize all utterances by a particular delegate about a particular proposal during the last N meetings. 19 | * [MBH] Previous discussion with YSV on using an LLM for navigation in a standard. 20 | * [IS] Important to make a difference between AI for the “subject matter aspects” of specifications vs. AI as a helping mechanism in the standardization process. Important for Ecma: long-term archival, simple tools are preferred. 21 | * [IS] How does Ecma and TC39 and the language community work together? 22 | * [MBH & IS] Standardization as a driver of language evolution. 23 | -------------------------------------------------------------------------------- /meetings/2024-05-29.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-3 2024-05-29 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ---------------- | 6 | | Mikhail Barash | MBH | UiB | 7 | | Yulia Startsev | YSV | Mozilla | 8 | | Alan Schmitt | AS | Inria | 9 | | Eemeli Aro | EAO | Mozilla | 10 | | Florian Merz | FM | Mozilla | 11 | | Istvan Sebestyen | IS | Ecma | 12 | | Jack Works | JWK | Sujitech | 13 | | James Hobson | JH | UiB | 14 | | Juho Vepsäläinen | JV | Aalto University | 15 | | Michael Coblenz | MC | UCSD | 16 | | Michael Dyck | | | 17 | | Michael Ficarra | MF | F5 | 18 | 19 | ## Meeting: 20 | 21 | * Housekeeping 22 | * Introductions 23 | * Publication of the Notes (these notes) 24 | * After each TG5 meeting, notes will be published in the TG5 repo. 25 | * [Meeting Cadence](https://github.com/tc39/tg5/issues/2) 26 | * TG5 meetings will be held at 4PM-5PM European time, once a month. 27 | * Subjects 28 | * MessageFormat 2.0 Study request 29 | * EAO: presented the summary of the issue. 30 | * YSV: This is specified in another standardization body. 31 | * MF: Regarding envisioned questions: what questions do we want _answered_, rather than what questions do we want asked. 32 | * EAO: A fundamental question: does this syntax feel nice when it’s used for its purpose, and what settings would you use this syntax in? 33 | * MC: Usability. Interview (the questions in the GitHub issue can be used as starting points). Instead of asking the users questions in a hypothetical setting, conduct a user study: give a candidate design and observe (e.g., what mistakes users make when given certain tasks). 34 | * YSV: TC39 blocked the proposal on the basis of lack of maturity. It’s not easy to deprecate things for the web. A study to help determine how well this syntax solves a given set of problems it was designed to solve, and how well the users respond. Cf.: a study on trusted types. 35 | * JWK: Question on how Message Format works for other software stacks 36 | * EAO: the data model for MessageFormat 2 seems to be universally applicable to all syntaxes. It’s relatively easy to transfer the data model from one representation to another. 37 | * JWK: this is approachable, if MessageFormat 2 doesn’t have features not representable in other formats. 38 | * EAO: bidirectional transformation 39 | * YSV, MF: how to make this actionable within TG5? What questions do we want to answer for ourselves? What are we testing? What will make TC39 more confident to advance the proposal? The meta question for TC39 is whether Message Format 2 can be integrated in the web. 40 | * EAO: authors of Message Format 2 message will only use it occasionally - is the syntax suitable for that purpose? 41 | * MC (in chat): (1) to what extent does the proposal meet the functional needs? (2) how effective is the design at helping users achieve their needs (when their needs align with the features that have been selected)? 42 | * YSV: this is infrequently used syntax, we don’t want regex’s sophistication 43 | * YSV: next steps: continue the collaboration with the proposal champions. 44 | * MC: interested in helping 45 | * YSV, EAO: aiming at Unicode CLDR Autumn/Spring release. The Message Format working group has weekly calls. 46 | * MC, YSV, EAO: let’s have a break-out meeting with the Message Format working group in 3 weeks. For the next TG5 meeting, we will make an update. For the next break-out session and the TG5 meeting, Eemeli will share the invitation to the meetings to relevant folks. 47 | * [MF] Editors’ work on refining the formalism of the spec 48 | * This agenda item has been postponed until the next meeting. 49 | * [FM] training an LLM on specifications and generating documentation 50 | * YSV: Discussion of LLM for specifications has been brought up by members of TG5. Using LLMs to generate answers to user queries for MDN is a project taken on by Mozilla. We’ve invited Florian to talk about this 51 | * FM: We are able to answer user queries using LLMs trained on professional writers interpretation of the specs. It generates answers, and examples. But, (the important part), it gets details wrong. Especially for new spec data that hasn’t been processed by a human. The LLM will invent in this case based on other languages. 52 | * FM: Concrete example: Set methods were generated from the spec. It got wrong: what kind of object do set methods operate on, on a set like? Etc. 53 | * FM: As a tool for a technical writer who post-processes: It is super helpful for bootstrapping. It can really speed up things. But you need an expert who would be able to edit the output. We can’t trust it. 54 | * MC: have you tried combining this with synthesis? (potential [contact](https://cseweb.ucsd.edu/~npolikarpova/), [Related paper, not synthesis based](https://arxiv.org/abs/2306.09541), and a more [closely-related paper](https://arxiv.org/abs/2405.15880) 55 | * JH: Interested in the productivity difference, worked on traffic control software and we were using AI to write transcripts. Editors were less likely to find mistakes made by an AI than when they wrote them, themselves. Have you tried to quantify speedups? 56 | * FM: Not yet, on the agenda to look into this 57 | * FM: TODO: train a model on the spec and translated by hand results 58 | * TG5 Charter 59 | * MF: What are the resources that are lacking to make TG5 a success? 60 | * YSV: I think the biggest risk is that we don’t have enough time/people for the amount of work that goes through TC39 61 | * MBH: This is the goal of building the community around TG5 62 | * MC: two conferences where people may be interested: 63 | * https://2024.plateau-workshop.org 64 | * https://2024.splashcon.org/home/hatra-2024 65 | -------------------------------------------------------------------------------- /meetings/2024-06-26.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-4 2024-06-26 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ---------------- | 6 | | Mikhail Barash | MBH | UiB | 7 | | Yulia Startsev | YSV | Mozilla | 8 | | Michael Ficarra | MF | F5 | 9 | | Jesse Alama | JMN | Igalia | 10 | | Michael Dyck | MD | | 11 | | Juho Vepsäläinen | JV | Aalto University | 12 | | Michael Coblenz | MC | UCSD | 13 | | Eemeli Aro | EAO | Mozilla | 14 | 15 | ## Meeting: 16 | 17 | ### Subject: Editors' work on refining the formalism of the spec 18 | 19 | MF: (presentation) 20 | * [(§5.2.5)](https://262.ecma-international.org/#sec-mathematical-operations) numeric types 21 | * [(§6.2.2)](https://262.ecma-international.org/#sec-list-and-record-specification-type) proliferation of records (reducing core concepts) 22 | * [(§6.2.1)](https://262.ecma-international.org/#sec-enum-specification-type) spec enums 23 | * [(§5.2.7)](https://262.ecma-international.org/#sec-identity) identity 24 | * [(§6.2.4)](https://262.ecma-international.org/#sec-completion-record-specification-type) explicit completion record handling 25 | * [(§6.2.8)](https://262.ecma-international.org/#sec-abstract-closure) abstract closures 26 | * AO type signatures 27 | * explicit, principled integration points 28 | - host hooks 29 | - (Annex B) step replacements for normative optional / legacy 30 | - [(#2952)](https://github.com/tc39/ecma262/pull/2952) feature flags for joint requirements 31 | 32 | YSV: [executable specification] 33 | 34 | MF: [editors' use of the KAIST's tool] 35 | 36 | JMN: I'd love to see those math functions nailed down a bit more, but maybe that horse has left the barn? 37 | 38 | MF: [we review manually] 39 | 40 | MF: working on math functions (not as an editor). Fully define math sqr, other math functions, 41 | plan on introducing constraints on them, bounds on return values, monotonicity 42 | 43 | MC (in chat): It seems like really doing this would require translating the whole thing to a formal specification (e.g. in Coq). 44 | 45 | MD (in chat): Another barrier to machine execution is that it's difficult to extract the characteristics 46 | of the intrinsic objects and the relations between them. 47 | 48 | [message in chat]: It sounds like part of the problem is that the machine-readable specifications approaches are too hard for humans to read. I wonder if research could make machine-interpretable specs easier for humans to read. 49 | 50 | YSV: Are there any risks from how differently the specifications are written (natural language vs. formal spec)? 51 | 52 | MF: [the way they are written is converging] 53 | 54 | YSV: What about HTML spec? 55 | 56 | MF: [entire phrases in a natural language are used in the spec] 57 | 58 | YSV: getting used to HTML spec, natural languages phrases. Is it worthwhile to have a DSL 59 | for standardization of the web platform? 60 | 61 | MF: made a framework for specification. difficult to make it language-agnostic 62 | 63 | YSV: cross-specification. intentional backwards incompatibility. 64 | 65 | YSV: one other project is WebIDL. We at Mozilla have an automatic rewriter of interfaces to WebIDL. 66 | 67 | MF: yes, would be nice to consider the implications. webIDL integration 68 | 69 | MC (in chat): Do we know much about how the spec is used? e.g. who reads it and what questions they have? 70 | 71 | MF: considered consumers who reads the spec -- profiles of readers of the spec 72 | 73 | JMN (in chat): for new, in-progress JS features I've received feedback from JS engine implementors 74 | who are following the spec text basically line-by-line just to get a first implementation done. 75 | They've spotted ambiguities, errors. 76 | 77 | YSV: who is visiting the spec - we don't have the statistics. 78 | There isn't much guidance on how to read the spec. 79 | 80 | MC: impossible to have a natural language specification precise 81 | 82 | EAO (in chat): AFAIK, the ECMA spec visitor numbers are only for 83 | https://ecma-international.org/publications-and-standards/standards/ecma-262/, 84 | and not https://tc39.es/ecma262/ 85 | 86 | YSV: many people struggle with WASM spec, especially the proofs 87 | 88 | MF: yes, they have a flipped priority of consumers compared to ECMAScript 89 | -------------------------------------------------------------------------------- /meetings/2024-08-07.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-5 2024-08-07 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ---------------- | 6 | | Mikhail Barash | MBH | UiB | 7 | | Yulia Startsev | YSV | Mozilla | 8 | | Michael Dyck | MD | | 9 | | Richard Gibson | RGN | Agoric | 10 | | Jack Works | JWK | Sujitech | 11 | | Juho Vepsäläinen | JV | Aalto University | 12 | | Michael Coblenz | MC | UCSD | 13 | | Asbjørn Orvedal | AO | UiB | 14 | 15 | 16 | ## Meeting: 17 | 18 | ### Subject: UiB's work on PL standardization 19 | 20 | MBH: (presentation) 21 | 22 | JV: suggestion to compare with the open-source evolution 23 | 24 | JV: an interesting question to study is how a language's evolution process affects the adoption of a language 25 | 26 | JV: consider maturity levels of processes 27 | 28 | MC: Will you give recommendations to TC39 regarding the TC39 process? 29 | 30 | MBH: This work is a descriptive study. We can indeed give recommendations to TC39, and it'll be up to the committee on whether they'll follow them or not. 31 | 32 | MC: interesting to study how a process document itself evolves 33 | 34 | MC (in chat): https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration 35 | 36 | JV: about maturity levels: say, level 5 would mean that most mature level, the "ideal" process 37 | 38 | YSV: what an "ideal" process is, will differ between languages 39 | 40 | YSV: difference between standardization (which by definition requires multiple vendors) and evolution (can be done by a single vendor) 41 | 42 | JV (in chat): https://github.com/tc39/tg5/issues/4#issuecomment-2264699897 43 | 44 | ### Subject: [issue 4](https://github.com/tc39/tg5/issues/4) 45 | 46 | JV: the current discussion needs "crystallization" of the research question 47 | 48 | ### Subject: a study on MessageFormat 2.0 ([issue 3](https://github.com/tc39/tg5/issues/3)) 49 | 50 | MC: [(presentation)](https://www.icloud.com/keynote/02cT1PhpfxR6pNI_qwqDPWemw#MessageFormat) 51 | 52 | YSV: For MessageFormat, some of the questions that you asked here are very specific to MessageFormat. 53 | The thing about MessageFormat is that it's split between two standards bodies. 54 | That's part of the problem with it. 55 | I don't know if you've gotten this layer of the discussion with MessageFormat. 56 | So, it's been standardized in Unicode, 57 | and TC39 has blocked further work on MessageFormat because we can't be sure that the design in Unicode is the right one. 58 | So, one question I have for you is: how do we go about validating that the design that we've come to is the right one? 59 | 60 | YSV: Just a little context here, something I've noticed as we design in TC39 is this: 61 | as we design internally, there's this gradual shift, there's this idea, let's say, pattern matching. 62 | Everybody has an idea of what pattern matching, people have written pattern matching in Rust or in other languages and they want basically that, 63 | but then the question of how does this translate into something in JavaScript, is different. 64 | Then we iterate, we iterate, we iterate, and eventually we have something that nobody recognizes and the question is: 65 | is it still fulfilling the problem that introducing pattern pattern matching was supposed to solve? 66 | So, that's something I would be interested in for the case of MessageFormat to see to validate is this the right design. 67 | Is that an interesting problem? 68 | 69 | MC: Yes, definitely. I mean, I think about this in terms of expressiveness. 70 | There are two flavors: (1) can you actually solve the problems that you need to solve, 71 | and can you write the programs that you need to write? And then, 72 | (2) does it provide the kind of safety or structural properties that you wanted? 73 | You have to ask what the goals are. 74 | 75 | YSV: Yeah. 76 | 77 | MC: You can do an empirical comparison between what the language is good for and what the original goals were. 78 | There's a question of whether the original goals were the right goals? 79 | 80 | YSV: Yes, exactly. When we're designing, we sometimes get blinded a little bit by aesthetics and we see that happen pretty frequently in TC39. 81 | Something we've been trying to focus more on is that any introduction to the language needs to solve a real problem and that problem must 82 | be something that you can articulate. If you can't articulate it, then why are we introducing this new thing to the language? 83 | That's something that Mozilla has been doing pretty heavily in recent years because we've been finding this drift of purpose 84 | that a new language feature takes on, can make it really confusing to decide whether or not it should be let added to the language. 85 | 86 | YSV: And the risk here is when we add something to the web platform, it is there forever. We cannot take it back. 87 | What I was thinking with this work is actually: this would be a case study, we're starting to think out how do we protect against that drift to ensure: 88 | (1) that we really understand the problems that we're solving (we sometimes don't); 89 | (2) we have a way to validate those problems are being solved by the proposal. 90 | Those are some of my thoughts here. 91 | 92 | MC: I think that's really great. Maybe we should start with some sort of needs assessment, 93 | actually work with localizers, get a corpus of messages that they would like to have written but couldn't. 94 | And use that as a corpus with which to evaluate possible designs. If they can express all the things that they wanted to express, 95 | then that's a good start, at least in terms of expressiveness. 96 | It's a separate question about usability. 97 | 98 | YSV: Yeah. I wonder: because I haven't actually been involved in the design of this proposal, it's been my colleague, 99 | I wonder how much of this work they've already done. I did understand from him that this was partially done on his intuition, 100 | so I don't think they have a corpus, but they might have something. 101 | How involved are the champions with helping you understand what they want? 102 | 103 | MC: So far, I'm not sure who these people are yet. 104 | 105 | YSV: Probably you guys have had one meeting for sure, right? 106 | 107 | MC: I had one one meeting with EAO, I think. 108 | 109 | YSV: Good. 110 | 111 | YSV: So, there's another thing that is going through my head right now. 112 | The kind of scrutiny that would be brought on by this kind of work might not be scrutiny that's welcomed. 113 | This is also been a reason why introducing evidence-based work has been a struggle at TC39, because, first, 114 | it's hard work, second, the thing that you want might not be the thing that you get. 115 | But we need to work with the people who are the designers of the proposal in order to get that stuff. 116 | So, I would like to have what you described -- basically getting a corpus of how localizers behave now, 117 | and what they wish they could have written. 118 | That would have been very useful to do at the beginning of this work. 119 | 120 | YSV: And then using that to evaluate whether or not we've made the right design to solve the underlying problems. 121 | That would be really convincing. 122 | That would be, I think, that's the thing that would move the needle on TC39, because right now, 123 | the thing that's going to happen is it's currently in candidate status at Unicode, 124 | and it's going to come out of candidate status and no one can use it because it hasn't been used in TC39. 125 | So, TC39 is going to continue to not be convinced. 126 | 127 | YSV: Okay, I've been talking for a long time. Somebody else has their hand up. 128 | 129 | MBH: Juho, you had a question? 130 | 131 | Juho: I was just asking if you could have people, I mean ask the question, so just give more information. 132 | So they consider the context: they have people that are trying to learn the thing, and they have experienced people, 133 | they like to use some other tools, they know what to expect. And you have this clueless people, 134 | completely different groups. I think for the clueless, if you provided a good chatbot with the right context, 135 | that it understands the specification, you could look into how are they learning the specification, 136 | what kind of questions are they asking about the specification, what kind of tasks they have in mind, 137 | to get a better idea of what are they trying to learn. I think that would be how I might try to understand 138 | how somebody without any clue about the topic is getting into the topic. 139 | 140 | MC: It seems like, if I can be connected to a community of localizers... 141 | Is is there a place where these people gather? Or the mailing list? So, how would we find these people? 142 | 143 | YSV: The person to talk to to get access to that would probably be EAO and his collaborators. 144 | So, what's the status of your conversation with with him so far, is he excited about this work? 145 | 146 | MC: it's nit him that I was talking to... 147 | We had one meeting with [Erlango](https://github.com/echeran), 148 | that's who I talked to, not EAO. 149 | 150 | YSV: Okay, so you didn't speak with EAO. I can ask EAO if there is, first of all, if prior work has been done, 151 | and also who to get in touch with. We do have localizers here at Mozilla, 152 | but you said you didn't want just one company, right? 153 | 154 | MC: I mean you have they have to start somewhere. 155 | So you know those are the ones we have easy access to, that's probably a good place to start. 156 | 157 | YSV: Okay, I can ask around at my company. We're having an all hands next week. 158 | So I'll be talking directly to those people. 159 | 160 | MC: Okay, great, thank you. 161 | 162 | YSV: I'll update on the issue what the progress is there. 163 | 164 | MC: If you have a timeline, I can think about, 165 | because I need to put an [IRB](https://en.wikipedia.org/wiki/Institutional_review_board). 166 | 167 | YSV: I will try to get information from my side to you by the end of next week. 168 | I don't know if it would be fruitful though. 169 | 170 | MC: Okay, all right. 171 | 172 | MBH: Richard? 173 | 174 | RGN: There is also for that work a weekly meeting, open to anyone. 175 | It's chaired by [Addison Phillips](https://github.com/aphillips). It's on the TC39 calendar, 176 | so attending a session is probably a really good way to get information quickly. 177 | 178 | MC: Okay. So I don't quite understand, you're talking about the relationship between Unicode and TC39. 179 | I don't quite understand what that relationship is. Could you maybe explain that more, Yulia? 180 | 181 | YSV: So, the web platform in particular is quite layered. We take other specifications and we build on top of them. 182 | For example, we import the Unicode specification into the JavaScript specification in order to talk about how things are decoded. 183 | We have a modification also because we have to support an older version of Unicode, so there's been some drift between the two specifications. 184 | 185 | YSV: So, work is sometimes done in one body and then iterated on further in another body, and that's what's happening here. 186 | So, the actual message format, the syntax for it, is being done inside of Unicode, 187 | and it's going to the candidate phase now, I think. 188 | They're expecting to ship next year. 189 | 190 | YSV: But TC39 doesn't take all of Unicode, they take parts of it, parts that they decide are extremely stable and that they can build upon. 191 | So, the request here was: we want this new API in JavaScript called MessageFormat2 that will take this syntax from Unicode that was developed there, 192 | and imported into TC39. The editors effectively said no to this, because we don't know if the Unicode standard will actually be used. 193 | That's the biggest risk. And we don't know if it's actually solving the necessary problems. 194 | If we import it and it's not solving the necessary problems, then we've imported basically a dud, and it has to live on the web forever, 195 | whereas Unicode in the past has deprecated certain features. We can't do that. 196 | 197 | YSV: Layering, this is what TC39 is based upon, and then there are other things that are based upon TC39. 198 | So other specs layer on top of TC39, or you could consider them siblings, so that would be HTML, WebAssembly, 199 | and there's an entire community of interacting standards in this space. 200 | 201 | MC: I see. So, is that really the key differerence, like Unicode can deprecate features, and TC39 can't? 202 | 203 | YSV: Well, there are a number of differences, and that's one of them. For example, 204 | we still have to support unpaired surrogates, which I believe is no longer possible in Unicode, 205 | but we still support them. 206 | 207 | YSV: We have also in the past deprecated things in order to allow certain optimizations to be possible, 208 | but we did it because it was minimally backwards incompatible. There were some breakages, but we have to be very careful about it, 209 | as the impact of making a backwards incompatible change on the web is quite significant. 210 | 211 | MC: So, is that the issue with the unpaired surrogates? 212 | 213 | YSV: Yeah, that's why we can't remove this. 214 | 215 | MC: Yeah. Okay. 216 | 217 | MC: I mean, this seems like a really good place to start, just trying to find out what the needs are. 218 | So, I think if you can help connect me to people, I can start working on [IRB](https://en.wikipedia.org/wiki/Institutional_review_board). 219 | This isn't kind of study that requires deep experience to actually run the study. 220 | 221 | YSV: Yeah. 222 | 223 | MC: So I may be able to find somebody who can do it. 224 | 225 | YSV: Yeah, and you know, I would really so the thing that I would really like to approach this 226 | with is with the mind of this being the basis for a framework, long term. So we're trying some stuff out, 227 | seeing how the industry reacts to it. In the past I've tried to bring experimentation to TC39 and it hasn't been successful. 228 | Well, it was middilingly successful, but I think repeated attempts and trying to understand how best to get the committee 229 | to accept certain things, that's one thing that I think would be interesting from this work. 230 | So, yes, we are solving a concrete problem with MessageFormat, but with an eye to "this is the framework for validation of proposals". 231 | If that's interesting to you. Because there are other interesting things, you talked about the design space: 232 | "feature A versus feature B, does that work better"? Those are all interesting questions, 233 | in this case I'm particularly interested in is what we ended up with actually what we wanted. 234 | I will put you in touch with people. I am kind of with one foot in another area, so I may not be the best person for this, 235 | but I will try to get the right person to pick this work up. 236 | So, you will hear from me before at the end of next week for that. 237 | 238 | MC: Great, thank you. Okay, this is very promising. I'm excited. I think this is exactly what I want to do. 239 | -------------------------------------------------------------------------------- /meetings/2024-08-28.md: -------------------------------------------------------------------------------- 1 | # TC39-TG5-6 2024-08-28 2 | 3 | **Remote attendees:** 4 | | Name | Abbreviation | Organization | 5 | | ----------------- | ------------ | ------------------| 6 | | Mikhail Barash | MBH | UiB | 7 | | Yulia Startsev | YSV | Mozilla | 8 | | Chris de Almeida | CDA | IBM | 9 | | Aki Rose Braun | AKI | Ecma International| 10 | | Istvan Sebestyen | IS | Ecma International| 11 | | Jesse Alama | JMN | Igalia | 12 | | Juho Vepsäläinen | JV | Aalto University | 13 | | Michael Dyck | MD | | 14 | | Jack Works | JWK | Sujitech | 15 | | Asbjørn Orvedal | AO | UiB | 16 | 17 | 18 | ## Meeting: 19 | 20 | ### Subject: A project to implement a Proposal Management Tool 21 | 22 | MBH: ([presentation](https://docs.google.com/presentation/d/1ph2O4TMr0hjaYQTFLNEaxrlPLQv8IEFUktjtWLryi5s/edit?usp=sharing)) 23 | 24 | JWK (in chat): I wonder what programming language is this 25 | 26 | JMN (in chat): https://www.jetbrains.com/mps/ 27 | 28 | MD (in chat): Do you have a grammar validator, or is that a goal? 29 | 30 | MD (in chat): Would people access the tool over the web? 31 | 32 | JMN (in chat): +1 to the idea of making this web-accessible (and/or parallel to the JetBrains interfaces or whatever interface). 33 | It would also be nice to have a locally accessible web-based version of the tool. 34 | 35 | YSV (in chat): +1 36 | 37 | JMN (in chat): I'd love to have some kind of search functionality (especially for notes from previous meetings). 38 | 39 | JV (in chat): Could you migrate existing data (specs etc.) somehow automatically to the system? 40 | 41 | MD (in chat): So the tool has some sort of 'Save' or 'Commit' that updates a central repository? 42 | 43 | AKI (in chat): I understand the software, it has integrated version control with a commit dialog, 44 | and also it's all just flat files so one could commit/push/pull however their preferred workflow (CLI, standalone GUI software, etc). 45 | 46 | AKI (_paraphrased to reflect the general meaning rather than being a verbatim quote_): support the idea of the project 47 | 48 | CDA (_paraphrased to reflect the general meaning rather than being a verbatim quote_): is the suggestion that this tool would supercede the tools currently used by the committee? making sure this solution doesn’t create more problems/overhead 49 | 50 | MBH (_paraphrased to reflect the general meaning rather than being a verbatim quote_): no, the tool is supposed to be completely interoperable with the tools used by the committee, including GitHub repositories etc. The can also be used in "view-only". 51 | 52 | CDA (_paraphrased to reflect the general meaning rather than being a verbatim quote_): what about real-time collaborative editing? 53 | 54 | MBH (_paraphrased to reflect the general meaning rather than being a verbatim quote_): there is an initiative towards that being developed in connection to the JetBrains MPS language workbench 55 | 56 | AKI: tool seems to be useful for other committees, the ones that we personally know/collaborate with 57 | 58 | IS: some users need only admin background, some users need technical - how do they collaborate together? 59 | 60 | AKI: interesting to look into scheduling with constraints 61 | 62 | ### Subject: TPAC (W3C annual conference) 63 | 64 | AKI: For every relevant Ecma TC and TG, I'm going through the list and coming up with potentially interested WGs to go chat up. 65 | One risk/challenge is that there's already history between a given TG and WG that I don't know about, 66 | so I'm trying to gather as much info as possible. 67 | 68 | -------------------------------------------------------------------------------- /workshops/2024/102.md: -------------------------------------------------------------------------------- 1 | # TG5 Workshop (in-person meeting) co-located with the 102nd Meeting of TC39 2 | 3 | ## Venue 4 | 5 | * **Hosting institution:** Department of Computing, University of Turku, Finland 6 | * **Hosts:** [Jaakko Järvi](https://www.utu.fi/en/people/jaakko-jarvi) (University of Turku), Mikhail Barash (University of Bergen), Yulia Startsev (Mozilla) 7 | * **Date:** Monday 10th June 2024 8 | * **Time:** 09:00 to 14:00 EEST (Europe/Helsinki) 9 | 10 | ## Programme of the Workshop 11 | 12 | |Time|Topic| 13 | |---|---| 14 | |09:00 - 09:15|Welcome & TG5 Introduction| 15 | |09:15 - 10:00|Coffee and mingling| 16 | |10:00 - 11:00|TG5 Discussion: [Multiway Dataflow Constraint Systems](https://hotdrink.github.io/hotdrink/) and TC39 [Signals proposal](https://github.com/tc39/proposal-signals)| 17 | |11:00 - 11:15|Break| 18 | |11:15 - 12:00|Panel with TC39 members (Daniel Ehrenberg, Michael Ficarra, Shane F. Carr): "How does JavaScript evolve?"| 19 | |12:00 - 12:30|Talk by [Jaakko Järvi](https://scholar.google.fi/citations?user=0r1JzFEAAAAJ&hl=fi): "A decade of C++ standardization"| 20 | |12:30 - 14:00|Lunch & Networking| 21 | 22 | ## TG5 Discussion session at 10:00-11:00 23 | 24 | ### Discussion participants 25 | 26 | |Name|Abbreviation|Organization| 27 | |----|------------|------------| 28 | |Jaakko Järvi|JJ|University of Turku| 29 | |Daniel Ehrenberg|DE|Bloomberg| 30 | |Michael Ficarra|MF|F5| 31 | |Shane F. Carr|SFC|Google| 32 | |Juho Vepsäläinen|JV|Aalto University| 33 | |Fatih Uzunoglu|FU|University of Turku| 34 | 35 | ### Notes 36 | 37 | JJ: _(presented a summary of HotDrink)_ 38 | 39 | DE: _(presented a summary of the Signals proposal)_ 40 | 41 | SFC: Does this support async computation? 42 | 43 | DE: Signal evaluton mechanism is synchronous. But we do have some privimitves that are designed to support asynchrony. Watcher calls callbacks when a signal becomes potentially dirty. A reaction is scheduled for later. Chain asynchronous reactions in an unstructed ways means erroneous code. For `Computed`s, you can construct an async graph using signal actions. If you want to react when noone is listening to you, it's psosible with unwatch. 44 | 45 | SFC: Potential problems with a need to recompute the graph. 46 | 47 | DE: In this API, the goal is that it's a shared base to be used in multiple policies on how to handle async. Would be great to have a scheduler that's built-in in the system and can be shared. 48 | 49 | JV: What about undo-redo, time travel? 50 | 51 | DE: Time travel is perhaps the most advanced case of transactions. If you want to model react suspense, you need transcations. We are looking for algorithms for transcations. These are things folks can work on as open-source contributors. Library `signals.utils` constructs reactive data structures out of the base signals. 52 | 53 | JV: event source: scrolling, show progress in top, in reactive systen. Easy way to hook it into on-scroll event? 54 | 55 | DE: Two ways to model this: every time you get on-scroll, you update. Scroll handlers are a source of performance problems. If you have a signal that represents the state of the scroll, you can implement another dependent signal. More efficient. 56 | 57 | SFC: HotDrink has cyclic graphs, but signal is explicitly acyclic. Is there a way to model a cyclic graph in signals? 58 | 59 | DE: there is a dirty way used in react (antipattern). Would be interesting to understand why people still see this as an intuitive way to implement. We do need a proper planning algorithm. Each variable is modelled as a computed signal; visible in the `Computed`s. That could be a bridge. 60 | 61 | FU: if you have an event loop, can you process queue waiting, can you evaluate all of them, or manually? 62 | 63 | DE: it's the code you put on top of the signals core which will be responsible for handling asynchrony. Watcher. 64 | 65 | FU: so all signals can be in a list? 66 | 67 | DE: Yes. 68 | 69 | JV: will the proposal have value otside of the browser? 70 | 71 | DE: What's the use case? Build tool using signal algorithms to figure out the minimal set of things to rebuild. 72 | 73 | JV: (?) 74 | 75 | DE: Signals can be used as a synchronouzaion mechanism between the server and the client. Discuss the use cases in the repo issues. 76 | 77 | JJ: When you set up a chain of signals, the whole graph computed synchronusly? 78 | 79 | DE: get - synchronous; setting a chain - iteratively, so can be asyncronously 80 | 81 | JJ: can you say anything in relation to promise chains? 82 | 83 | DE: similarities. A different thing: promises - the function coloring problem. With signals, it's implictly, global var tracking the dependencies, you operate in the world of normal JS values. The other thing: promise: `.then` - from the definition to the usage, signals: (?) 84 | 85 | JV: (?) 86 | 87 | DE: JS code between every async call, you can count on it being uninterrupted (cooperative multitasking) 88 | 89 | JJ: coalsecing events. We looked into flushable promises. When you do debouncing, throttling events, chains of dependencies. (?) You can tell the promise "hurry up". 90 | 91 | JJ: _(explained flushable promises)_ 92 | 93 | JV: abort control lock can be used 94 | 95 | DE: what happens if the response comes before the user finished typing? 96 | 97 | JV, DE: glitches in reactive programming 98 | 99 | JV: for every transition, they forced to model everything. can we take a state machine and implement it using signals? 100 | 101 | DE: implementing `XState` with signals. Another OSS contribution opportunity. 102 | 103 | JJ: _(on a whiteboard: an example of a glitch)_ 104 | 105 | DE: formal methods to verify - to enumerate signals algoithms whcih will be glitch-free 106 | 107 | JJ, DE: flushable promises use case 108 | 109 | DE: other solutions might exist: `tee`, too awkward to use in praftice. Another: modeling this with signals: signals can evaluate to a promise. They also have an invalidation mechanism where you (?) the underlying source and the (?) knows that they are no longer valid. Can we use the invalidation mechaisns here because it solves the coloring problen. 110 | 111 | JJ: _(example of flushable promises)_ 112 | 113 | JV: what happens if the computation(s) in the chain fails? 114 | 115 | JJ: didn't thought about it 116 | 117 | DE: (?) 118 | 119 | FU: rapid burst of events 120 | 121 | JJ: event caosliscneing: throttling (throw away events - you only handle every 100 ms), debouncing (events in a row - every new event within that period - you are reseting the timer) 122 | 123 | JJ: there is ongoing work on adding the concepts of observables 124 | 125 | SFC: (?) 126 | 127 | JJ: (?) 128 | -------------------------------------------------------------------------------- /workshops/2024/104.md: -------------------------------------------------------------------------------- 1 | # TG5 Workshop (in-person meeting) co-located with the 104nd Meeting of TC39 (Tokyo, Japan, October 2024) 2 | 3 | ## Venue 4 | 5 | * **Hosting institution:** [Computing Software Group](https://www.csg.ci.i.u-tokyo.ac.jp/en/), University of Tokyo, Japan 6 | * **Hosts:** Prof. [Shigeru Chiba](https://chibash.github.io/) (University of Tokyo), Yulia Startsev (Mozilla), Mikhail Barash (University of Bergen) 7 | * **Date:** Friday 11th October 2024 8 | * **Time:** 09:00 to 14:00 JST (Japan/Tokyo) 9 | * **Location:** [1-1-1 Yayoi, Bunkyo-ku, Tokyo](https://www.csg.ci.i.u-tokyo.ac.jp/en/contact.html). The workshop is held at the lecture room **Hilobby** on the **6th floor** of the **[I-REF building](https://www.csg.ci.i.u-tokyo.ac.jp/en/contact.html)**. When you come to the building, take an elevator to the 6th floor. The room will be in front of the elevator. 10 | * **Trivia:** The University of Tokyo is the oldest and largest national university in Japan. The TG5 Workshop will be held on the main campus of the University of Tokyo, which is the oldest and largest national university in Japan. It is located in the city center of Tokyo and has good access to three subway stations. The campus is next to Ueno park, where there are many museums, hotels, and restaurants. The campus is a popular tourist spot in Tokyo and you can see the famous Red gate built in the Edo era as well as historically important university buildings. 11 | 12 | 13 | ## Programme of the Workshop 14 | 15 | |Time|Topic|Presenter(s)| 16 | |---|---|---| 17 | |09:00 - 09:10|**Welcome to TG5 Workshop and the Computing Software Group**|[Shigeru Chiba](https://chibash.github.io/), [Yulia Startsev](https://x.com/codehag), [Mikhail Barash](https://www4.uib.no/en/find-employees/Mikhail.Barash)| 18 | |09:10 - 09:40|[**Keynote: Why Syntax Matters**](https://dl.acm.org/doi/10.1145/3567512.3571831)|[Shigeru Chiba](https://chibash.github.io/)| 19 | |09:40 - 10:00|**Discussion on syntax and [grammar models](https://ceur-ws.org/Vol-2707/oopslepaper4.pdf)**|[Shigeru Chiba](https://chibash.github.io/), [Mikhail Barash](https://www4.uib.no/en/find-employees/Mikhail.Barash)| 20 | |10:00 - 10:45|[**Bringing the WebAssembly Standard up to Speed with SpecTec**](https://dl.acm.org/doi/pdf/10.1145/3656440)|[Dongjun Youn](https://plrg.kaist.ac.kr/members/%EC%9C%A4%EB%8F%99%EC%A4%80-dongjun-youn)| 21 | |10:45 - 11:15|coffee break|| 22 | |11:15 - 11:45|[**Syntax Checking by Type System**](#syntax-checking-by-type-system-tomoki-nakamaru)|[Tomoki Nakamaru](https://tomokinakamaru.github.io/)| 23 | |11:45 - 12:15|[**Interactive Programming for Microcontrollers by Offloading Dynamic Incremental Compilation**](https://dl.acm.org/doi/10.1145/3679007.3685062)|[Fumika Mochizuki](https://2024.ecoop.org/profile/fumikamochizuki)| 24 | |12:15 - 13:00|[**TC39 Keynote and Panel discussion**](#tc39-keynote-and-panel-discussion-aki-rose-braun-michael-ficarra-yulia-startsev-jesse-alama-oliver-medhurst)|[Aki Rose Braun](https://akiro.se/), [Michael Ficarra](https://x.com/smooshmap), [Yulia Startsev](https://x.com/codehag), [Jesse Alama](https://jessealama.net/), [Oliver Medhurst](https://goose.icu/), [Ross Kirsling](https://rkirsling.github.io/), [Shane F. Carr](https://www.sffc.xyz/)| 25 | |13:00 - 14:00|lunch and mingling|| 26 | 27 | ## Abstracts of the talks 28 | 29 | ### [Bringing the WebAssembly Standard up to Speed with SpecTec (Dongjun Youn)](https://dl.acm.org/doi/pdf/10.1145/3656440) 30 | We present SpecTec, a domain-specific language (DSL) and toolchain that facilitates both the Wasm specification and the generation 31 | of artifacts necessary to standardize new features. SpecTec serves as a single source of truth — from a SpecTec definition of the Wasm semantics, 32 | we can generate a typeset specification, including formal definitions and prose pseudocode descriptions, and a meta-level interpreter. 33 | Further backends for test generation and interactive theorem proving are planned. We evaluate SpecTec’s ability to represent the latest 34 | Wasm 2.0 and show that the generated meta-level interpreter passes 100% of the applicable official test suite. We show that SpecTec is highly 35 | effective at discovering and preventing errors by detecting historical errors in the specification that have been corrected and ten errors in five 36 | proposals ready for inclusion in the next version of Wasm. Our ultimate aim is that SpecTec should be adopted by the Wasm standards community and 37 | used to specify future versions of the standard. 38 | 39 | ### [Syntax Checking by Type System (Tomoki Nakamaru)](#syntax-checking-by-type-system-tomoki-nakamaru) 40 | Building a library with a fluent interface, a library that supports method chaining, 41 | is a promising way to implement our own language inside an object-oriented programming (OOP) 42 | language like JavaScript. In this talk, the presenter will introduce how we can utilize the type 43 | system of an OOP language to check the syntax of a method call chain (or a program expression) 44 | written with the fluent library. 45 | 46 | ### [Interactive Programming for Microcontrollers by Offloading Dynamic Incremental Compilation (Fumika Mochizuki)](https://dl.acm.org/doi/10.1145/3679007.3685062) 47 | This was a talk originally presented at MPLR 2024. In this talk we present our language named BlueScript. 48 | Like MicroPython, it is a language for IoT devices but with syntax borrowed from TypeScript. 49 | To enable both interactive execution and good execution performance on microcontrollers with a small amount of memory, 50 | BlueScript adopts dynamic incremental compilation and offloads it to a host PC. 51 | Furthermore, despite the syntactical similarity, the semantics of BlueScript is largely different from TypeScript and JavaScript 52 | so that compilation time will be short and compiled binary runs fast. 53 | 54 | ### [TC39 Keynote and Panel discussion (Aki Rose Braun, Michael Ficarra, Yulia Startsev, Jesse Alama, Oliver Medhurst)](#tc39-keynote-and-panel-discussion-aki-rose-braun-michael-ficarra-yulia-startsev-jesse-alama-oliver-medhurst) 55 | This talk will introduce TC39, the committee responsible for the development and maintenance of the JavaScript language. 56 | The presentation will provide an overview of the committee's processes, detailing the various stages a new feature proposal undergoes, 57 | from its initial conception to its inclusion in the official language specification. We will discuss some of the proposals reviewed 58 | during the TC39 Plenary meeting held earlier during the week. 59 | * [The TC39 Process](https://tc39.es/process-document/) (A. Braun) 60 | * Proposal [_Concurrency Control_](https://github.com/tc39/proposal-concurrency-control) ([slides](https://docs.google.com/presentation/d/1Pf0s8XXVCxlERmJU_YZY6YwEULXDS_HaBH3zuMUyrPo)) (M. Ficarra) 61 | * Proposal [_Decimal_](https://github.com/tc39/proposal-decimal) (J. Alama) 62 | * [Compiling JS ahead-of-time](https://github.com/CanadaHonk/porffor) (O. Medhurst) 63 | * Proposal [MessageFormat](https://github.com/tc39/proposal-intl-messageformat) (S. F. Carr) 64 | -------------------------------------------------------------------------------- /workshops/2025/106.md: -------------------------------------------------------------------------------- 1 | # TG5 Workshop (in-person meeting) co-located with the 106th Meeting of TC39 (Seattle, USA, February 2025) 2 | 3 | ## Venue 4 | 5 | * **Host:** Michael Ficarra ([F5](https://github.com/orgs/tc39/teams/member-f5)), Mikhail Barash (University of Bergen), Yulia Startsev (Mozilla) 6 | * **Date:** Friday 21st February 2025 7 | * **Time:** 10:00 to 14:00 PST (US/Pacific) 8 | * **Location:** [F5 Tower, 801 5th Ave, Seattle, WA 98104, United States](https://goo.gl/maps/TJSNU3CzviyRN4Rk6) 9 | 10 | 11 | ## Programme of the Workshop 12 | 13 | |Time|Topic|Presenter(s)| 14 | |---|---|---| 15 | |10:00 - 10:30|Welcome to TG5 Workshop & What is TG5|[Mikhail Barash](https://www4.uib.no/en/find-employees/Mikhail.Barash)| 16 | |10:30 - 11:00|Updates on the [MessageFormat study](https://github.com/tc39/tg5/issues/3)|[Shun Kashiwa](https://shun-k.dev/) (University of California San Diego)| 17 | |11:00 - 11:15|Coffee break|| 18 | |11:15 - 12:00|Discussion: studies on TC39 proposals|[Shun Kashiwa](https://shun-k.dev/), N.N.| 19 | |12:00 - 12:30|Formalizing JS decimal numbers with the Lean proof assistant|[Jesse Alama](https://github.com/jessealama)| 20 | |12:30 - 12:45|Uncanny Valleys in Language Design ([SNAPL 2017 paper](https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.SNAPL.2017.9))|[Mark Miller](https://papers.agoric.com/authors/mark-s-miller/)| 21 | |12:45 - 13:00|A parser generator template literal tag generating template literal tags ([repo](https://github.com/erights/quasiParserGenerator))|[Mark Miller](https://papers.agoric.com/authors/mark-s-miller/)| 22 | |13:00 - 14:00|lunch|| 23 | 24 | ## Abstracts 25 | 26 | ### Updates on the MessageFormat study (Shun Kashiwa, University of California San Diego) 27 | 28 | Internationalization and localization are critical for making software accessible to global audiences, 29 | yet their implementation often poses challenges due to linguistic diversity and complexity. 30 | MessageFormat 2 (MF2), a successor to MessageFormat 1.0, aims to overcome these challenges by offering 31 | enhanced expressivity and usability. This study evaluates MF2’s usability and effectiveness through a think-aloud 32 | user study with software engineers and translators. Ten participants were tasked with comprehension, writing, 33 | and translation tasks using MF2. The results reveal that MF2’s syntax is generally approachable for both software 34 | engineers and translators, though the two groups provided distinct feedback. Software engineers reported limitations 35 | in MF2’s expressivity and spent time navigating its functions and parameters to compose messages. Translators, 36 | on the other hand, found the `.match` syntax challenging but faced no difficulty translating existing MF2 messages. 37 | In addition, MF2 exhibited shortcomings in handling certain locale-specific linguistic rules, such as Turkish suffixes 38 | and Danish ordinal forms. Overall, our findings suggest that MF2 holds promise as a standard framework for defining 39 | translatable messages. Expansion of the default function registry, comprehensive documentation, and the development 40 | of supporting tools such as GUI editors can foster its broader adoption. 41 | 42 | ### Formalizing JS decimal numbers with the Lean proof assistant (Jesse Alama, Igalia) 43 | 44 | IEEE 754 is a specification for both floating-point numbers and arithmetic, 45 | both in decimal and binary notation, the latter being the more commonly understood part. 46 | As part of the [effort](https://github.com/tc39/proposal-decimal/) to add decimal numbers to JavaScript, 47 | based on IEEE 754, we are using the [Lean proof assistant](https://lean-lang.org/) to help make sure that we are getting the details just right. 48 | Although formalization is not a requirement for advancing through the Ecma TC39 stage process, 49 | in some cases it might be helpful for the standards author. In the case of the decimal proposal, 50 | the nature of the data -- numbers -- is fundamental enough, and some details of IEEE 754 unexpected enough, 51 | that formalization may be warranted to help make sure we're getting everything right. 52 | -------------------------------------------------------------------------------- /workshops/2025/108.md: -------------------------------------------------------------------------------- 1 | # TG5 Workshop (in-person meeting) co-located with the 108th Meeting of TC39 (A Coruña, Spain, May 2025) 2 | 3 | ## Venue 4 | 5 | * **Hosts:** [Miguel Ángel Alonso Pardo](https://pdi.udc.es/en/File/Pdi/E269E) (University of A Coruña), 6 | [Mikhail Barash](https://www4.uib.no/en/find-employees/Mikhail.Barash) (University of Bergen), 7 | [Yulia Startsev](https://github.com/codehag) (Mozilla) 8 | * **Date:** Tuesday 27th May 2025 9 | * **Time:** 10:00 to 14:00 CEST 10 | * **Location:** [Room "Aula de Grados", Building "Facultad de Informática", Campus de Elviña, Universidade da Coruña](https://maps.app.goo.gl/JFPUTMfGSRZuJSoT6) 11 | 12 | ## Registration 13 | 14 | - Registration form: https://forms.gle/TkpzzC2Q8vLFkccy8 15 | 16 | ## Programme of the Workshop 17 | 18 | |Time|Topic|Presenter(s)| 19 | |---|---|---| 20 | |10:00-10:10|Welcome to TG5 Workshop|Miguel Alonso Pardo, Mikhail Barash, Yulia Startsev| 21 | |10:10-10:40|Declarative Programming versus Declarative Problem Solving|[Pedro Cabalar](https://www.dc.fi.udc.es/~cabalar/) (University of A Coruña)| 22 | |10:40-11:10|[Polyhedral](https://en.wikipedia.org/wiki/Polytope_model) optimization and sparse computations|[Gabriel Rodríguez](https://pdi.udc.es/en/File/Pdi/H997G) (University of A Coruña)| 23 | |11:10-11:40|The [Gleam](https://gleam.run/)ing bridge between JavaScript and the BEAM|[Laura M. Castro](https://lauramcastro.github.io/) (University of A Coruña)| 24 | |11:40-12:15|coffee break|| 25 | |12:15-12:45|[Concurrency Control](https://github.com/tc39/proposal-concurrency-control) Proposal Overview|[Michael Ficarra](https://github.com/michaelficarra) (F5)| 26 | |12:45-13:15|[MessageFormat](https://messageformat.unicode.org/): The future of [i18n](https://en.wikipedia.org/wiki/Internationalization_and_localization) on the web|[Ujjwal Sharma](https://github.com/ryzokuken) (Igalia)| 27 | |13:30|lunch|| 28 | 29 | ## Abstracts 30 | 31 | ### Declarative Programming versus Declarative Problem Solving (P. Cabalar) 32 | 33 | Declarative programming ideally follows the principle of describing the task to be achieved ("what" to do) 34 | rather than the sequence of steps to achieve that task ("how" to do it). Yet, declarative programming 35 | languages must allow implementing algorithms, that are nothing else but sequences of steps (formally, 36 | Turing machines). So a declarative program is also a computational model normally depending on some 37 | implicit control strategy of the language interpreter that may affect to computational complexity or 38 | even termination. In Logic Programming (LP), for instance, this was summarized by the well-known informal 39 | equation "Algorithms = Logic + Control" stated by Robert A. Kowalski. Declarative Problem Solving goes one 40 | step forward: it consists in finding solutions to computational problems by exclusively using a formal 41 | specification of the relevant domain knowledge and the conditions imposed by the problem to be solved. 42 | Solutions are then computed by generic solvers rather than by specific, problem oriented algorithms that 43 | describe the steps to follow. This approach is applied to different types of computational problems, such 44 | as combinatorial, optimization, numerical constraints, planning, scheduling or temporal constraints. In 45 | the talk, we will discuss some important differences of Declarative Problem Solving with respect to 46 | Declarative Programming, using the LP paradigm of Answer Set Programming as an illustration. 47 | 48 | ### Polyhedral optimization and sparse computations (G. Rodríguez) 49 | 50 | Sparse data structures are commonly used in many real-world computations for efficiently representing 51 | datasets with a high volume of zero values. Sparse structures are widely used in areas like physics 52 | simulations, graph processing, and machine learning. Storing (and computing with) only the nonzero 53 | elements in the structure saves both memory and computation time. 54 | Traditional sparse formats, like Compressed Sparse Row (CSR), are based on the (possibly compressed) 55 | enumeration of nonzero positions through arrays of coordinates. This allows to write generic executors 56 | that implement computational kernels for arbitrary sparse structures, but increases the memory footprint 57 | of the computation and obfuscates computation structure, complexifying compiler optimizations, e.g., 58 | vectorization. 59 | This presentation introduces polyhedral optimization, a powerful mathematical framework traditionally used 60 | by compilers to optimize dense loop nests. We will explore how the polyhedral abstractions can be used to 61 | represent sparse computations, optimizing the computation footprint and exposing computation structure to 62 | the optimizer. 63 | 64 | ### The GLEAMming bridge between JavaScript and the BEAM (L. M. Castro) 65 | 66 | Gleam is a new language for Erlang's BEAM virtual machine that brings in a robust type system, 67 | something long awaited by part of the BEAM community. Gleam maintains the expressiveness of functional 68 | programming and profits from the highly concurrent fault-tolerant Erlang runtime. 69 | The design of the language is very concise, so it features no null values, no exceptions, 70 | simple error messages. And on top of it all, JavaScript is supported as a compile target, 71 | so Gleam code can be run in a browser or any other JS-enabled runtime. 72 | During this session, we will quickly (1) go over the history of the BEAM and the recent explosion 73 | of new languages for this platform, helping the growth of the community in different directions; 74 | (2) learn the basics about Gleam. 75 | --------------------------------------------------------------------------------