\chapter{Background}

\section{Technical Committee 39}

Technical Committee 39  is the committee which maintains ECMA-262~\cite{ecma262}, the language standard for ECMAScript, and other related standards. They develop this standard following the TC39 process~\cite{TC39Process} for standard extension. 

Technical Committee 39 (abbreviated as TC39) is a group within ECMA international, whose main goal is to develop the language standard for ECMAScript (JavaScript) and other related standards. These related standards include: ECMA-402, the internalization API of ECMA-262, ECMA-404, the standard for JSON, ECMA-414, the ECMAScript specification suite standard. The members of the committee are representatives from various companies, academic institutions, and various other organizations from all across the world interested in developing the ECMAScript language. The members are usually people working wit JavaScript engines, tooling surrounding JavaScript, and other sections related to the JavaScript language.  


\subsection{ECMA-262 Proposals}

This section will contain what is a proposal, and how proposals are developed in TC39 for the ECMA-262 language standard. 

\subsection*{TC39 Process}

The TC39 process~\cite{TC39Process}, is a process document describing how the extension ECMA-262 is performed. A suggested change to the ECMA-262 standard is in the form of a \emph{proposal}. This process documents describes the stages a proposal has to pass through to be accepted into the ECMA-262 standard. 

Stage 0 consists if ideation. The purpose of this stage is to allow for exploration and ideation around what part of the current version of ECMAScript can be improved, and then define a problem space for the committee to focus. 

Stage 1, is the point the committee has started taking the suggested addition and will consider it. The are several requirements to enter this stage: A champion has to be identified, a champion is a member TC39 who is responsible for the proposal. A rough outline of the problem, and a general shape of a solution. There has to have been discussion around key algorithms, abstractions and semantics of the proposal. Potential implementation challenges and cross-cutting concerns have to have been identified. All these described requirements have to be captured in a public repository. Once all these requirements are met, a proposal is accepted into stage 1. During this stage, the committee will work on designing a solution, and resolve any cross-cutting concerns discovered. 

Stage 2, a preferred solution has been identified. Requirements for a proposal to enter this stage: All high level APIs and syntax have to be described in the proposal document. Illustrative examples of usage created. An initial specification text have to be created. In this stage, the solution identified have to be refined, minor details ironed out, and experimental implementations will be created. 

Stage 2.7, the proposal is principally approved, and has to be tested and validated. To enter this stage, the major sections of the proposal have to be complete. The specification text is finished, and all reviewers of the specification have approved. Once a proposal has entered this stage, testing and validation will be performed. This is done through the prototype implementations created in stage 2, and all features of the proposal is validated. 

Stage 3, proposal is recommended for implementation. Once a proposal has been sufficiently tested and verified, it is moved to stage 3. During stage 3, the proposal is implemented in all major engines. During this stage, the proposal is tested for web compatibility issues, or integration issues in the major JavaScript engines. 

Stage 4, the proposal is completed and included in the standard. 

At this point, the committee will devote time to examine the problem space, and discuss possible solutions. 




Proposals - what is a proposal (has to include motivation, prior art --- see what we had in the JavaZone talk about proposals)



\section{AST and Babel}



Abstract Syntax Trees, Babel, AST traversal


\section{Source code Querying}


\section{Language Workbenches}



\section{Domain Specific languages}