Abstract
ECMA 262 is all about ECMAScript, a.k.a JavaScript or simply JS. It is the living document where is writen the specification of the language. What are the stages of the specification process?, What is considered a finished proposal? How decisions are made? Those are some of the questions that EMCA 262 has answers, and I am going to review here.
ECMAScript® Language Specification
The ECMA 262 is the official document where the current specification or standard of EMCAScript programming language (JavaScript, JS) has been defined. In their own words, the ECMA 262 is ‘the most accurate and up-to-date ECMAScript specification’. The document not only contains the most recent version of the specification, but it also contains all past finished proposals.
A finished proposal is one that has reached stage 4 in the proposal process (see below all the stages). Such process is clearly defined in the process document, and here I want to give some account of it. First, in the document process is writen the way adopted by the TC39 (Technical Committee 39) as the procedure to make decisions about the ECMAScript specification. The process has six stages, and the TC39 operates by concensus, and has the discretion of alter the specification as it sees fit.
All changes to the language follow a process of evolution from the initial idea to the fully specified feature completed. The six stages of the process are:
- Stage 0: There is a new proposal, but it is not currently being considered by the committee.
- Stage 1: The new proposal is under consideration. The committee expects to devote time to examining the identified problem space, the full breadth of possible solutions, and cross-cutting concerns.
- Stage 2: The committee has chosen a preferred solution or solution space, but the design is a draft and may still change significantly. The committee expects the feature to be developed and eventually included in the standard, but due to reasons that may not be apparent at this stage, the feature may never be included in the standard.
- Stage 2.7: The proposal is approved in principle and undergoing validation. The solution is complete and no further work is possible without feedback from tests, implementations, or usage. No changes to the proposal will be requested by the committee aside from those elicited through testing, implementation, or usage experience.
- Stage 3: The proposal has been recommended for implementation. No changes to the proposal are expected, but some necessary changes may still occur due to web incompatibilities or feedback from production-grade implementations.
- State 4: The proposed feature is complete and ready to be included in the standard. No further changes will be made to the proposal.
The purpose of the Stage 0 is ideation and exploration. In this stage the problem space of the new proposal is defined. For example, some researching about how other programming languages have solve the problem, identifying potential challenges and describing the shape of some possible solutions.
The purpose of Stage 1 to design the solution. It means making the case for a particular solution or solution space. The Stage 2 has the purpose of refining the solution. For example, working out minor details such as ordering of observable effects, hadling of invalid inputs, API names, and so on. In that state some experimentals implementations can be produced.
The purpose of the Stage 2.7 is to test and validate the solution. A more rigorous implementation must be validated through the development of a comprehensive test suit. In the Stage 3, the new feature must have sufficient testing and appropriate pre-implementation experience. Some commpatibility or integration issues may be discovered on this stage. Finally, in the Stage 4 the proposed feature is complete and ready to be included in the official specification of the language. In this 4th stage, at least two compatible implementations should pass the Test262 acceptance tests, and those two implementations must have significant experience in the field.
The Process of Achieving Concensus
The TC39 make decisions through concensus. According the the process document, during the discussion of a proposal any aspect may be addressed. The feedback is very important especially realted to concerns or when it is relevant to advance in the stage process. Some constraints may be proposed for a desired property and asking rationale support for the proposal of a specific property. All the proposals should be validated with care because the evolution of an open Web Standard is in their hands. Concensus may not be achiveved when reasonable doubts about constraints are floating in the TC39. It is always possible tha the champion of the proposal make changes and return to the committee asking for concensus. The proposals may be withdrew or reverted to earlier stages as well. For all of that concensus is necessary.
The Responsibility of Evolving a Global Well Known Programming Language
One of the principles of the W3C (The World Wide Web Consortium) is ‘Do not break the Web’. Because EMCAScript is one of the most used programming language on this planet, the responsibility of making changes on the official specification deserves all the care and the process above described. It is not only the responsibility for the well informeed, tested, controlled change and evolution of a programming language, but the future of the Web as an open standard as well.