\chapter{Introduction}

The development of the programming language ECMAScript, which is defined by the ECMA-262 language standard, is worked on by Technical Committee 39. The committee has the responsibility to explore proposals suggested for addition to ECMASript. During this process, proposals go through many iterations in the exploration process of solutions to the problem identified in the proposal. During this process, the community of JavaScript developers can give feedback on proposed solutions. This feedback has to be of some quality, and it is therefore adamant that the user's giving feedback understand the proposal well. This thesis suggests a way of presenting proposals to users by exploiting their familiarity with their own code. 

The idea behind using the user's own code, is to lower the barrier to understand a proposal. A user most likely understands the code they themselves have written, therefore there is no need to understand the initial premise of the example. Therefore, this will allow the user to fucus solely on the concepts the proposal introduces. This idea applies to syntactic proposals, which are proposals that contains either no, or very limited change to functionality, and no change to semantics. 

This thesis discusses a way of defining transformations of code specifically for syntactic proposals. These transformations are used to showcase a syntactic proposal to users by transforming code the user's are already familiar with. The theory is this will help user's understand proposals faster and easier, as they are already familiar with the code the proposal is being presented in. The two proposals discussed in this thesis to evaluate the tool are "Do Expression"~\cite{Proposal:DoProposal} and "Pipeline"~\cite{Pipeline}.

The language defined in this thesis is titles \DSL, and allows for structured template queries to be written, these templates are used to search for code that is applicable to a proposal. A code snippet being applicable to a proposal, means it could have been written using that proposal. These queries come with a definition of a transformation, which will use the matched code snippet in the user's code, and transform it to use the features of the proposal. This newly transformed code can then be presented to the user along with the original unchanged code. This allows a user to see an example of the proposal being applied, and they can then give feedback on the proposal based on that. 

Every template uses a notion of wildcards, which are sections of the template that is not defined using JavaScript, but a custom block containing an identifier, and a AST node type expression. 











