master/chapter/introduction.tex

\chapter{Introduction}

The development and evolution of the programming language ECMAScript---which
is defined by the ECMA-262 language standard---is
done by the Technical Committee 39 of Ecma International.
The committee has the responsibility to investigate proposals
suggested for addition into the ECMASript language.
During this process,
proposals go through numerous iterations
of improving the solution space of the problem identified in a proposal. 
The community of JavaScript developers
can give feedback on proposals;
this feedback has to be of a certain quality---it is,
therefore,
crucial that the users are confident in their understanding of the proposal,
the suggested solution,
and its potential corner cases.
To aid users in this understanding,
the description of a proposal is expected
to illustrate the solution by presenting several
examples---in form of ECMAScript code snippets---that
highlight various scenarios for the use of
the functionality suggested in a proposal.
In this thesis,
we suggest a way of demonstrating these scenarios in a user's own codebase.
We conjecture this will lower the barrier of understanding a proposal,
and will allow the user to focus solely on the concepts a proposal introduces. 

This thesis discusses a way of defining transformations of code specifically for \emph{syntactic} proposals---these are proposals that do not introduce any new semantics to the language, but merely improve the ergonomics of how the code is written.
The idea is to identify code fragments in a user's codebase
to which a proposal can be applied,
and then replace that code with an equivalent code
that uses the functionality introduced in a proposal.

We developed a domain-specific language called ``JSTQL'' (for ``JavaScript Transformation Query Language'')
for specifying queries and transformations on JavaScript code.
This DSL utilizes JavaScript templates to query user code and
to define how the matched code should be transformed.
To parse both the templates and user code,
we employ the Babel~\cite{Babel} library.
The templates defined in \DSL{} may include variables---referred to as \emph{wildcards}---which are special blocks written inside the template.
These blocks facilitate matching against arbitrary code,
and transforming that code according to the specified transformation;
this allows the transformed code to maintain its \emph{context}.
To specify what kind of code a wildcard will match against,
we use \emph{type expressions},
which are Boolean propositions on the node types as defined in the Babel abstract syntax tree specification. 

The evaluation of the transformation tool implemented in this thesis involved specifying the proposals ``Do Expression''~\cite{Proposal:DoProposal}
and ``Pipeline''~\cite{Pipeline} in our DSL.
These specifications were applied to existing large codebases
in order to assess the functionality of the transformations.
The results obtained from this process confirmed the functionality of the tool, and  provided insights into how significant of an ``impact''
the design decisions in each proposal might have on existing codebases.  

The transformation tool presented in this thesis
is meant to be the initial step in creating a language workbench-like
tool for designing widely adopted programming languages.
We created the core machinery of transforming code based on a proposal specification,
while implementing ways to present this to users and gather feedback on proposals is left up to future work. 


%A proposal describes a the technicalities of a suggested change to the language and its requirements, this is done by a language specification, motivation for the idea, and general discussion around the proposed change. A proposal ideally also needs backing from the community of users that use ECMAScript, this means the proposal has to be presented to users some way. This is currently done by many channels, such as polyfills, code examples, and as beta features of the main JavaScript engines, however, this paper wishes to showcase proposals to users by using a different avenue.  

%Users of ECMAScript have a familiarity with code they themselves have written. This means they have knowledge of how their own code works and why they might have written it a certain way. This project aims to utilize this pre-existing knowledge to showcase new proposals for ECMAScript. This way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal authors.




%searching the user's code for such  snippets and transform them to use the proposals proposed solution. 


%\textcolor{red}{write that a proposal description contains several examples, but those are artificial/%taken out of the context, but we want the users to actually play with the proposal}
%In this thesis, we suggest an \textcolor{red}{approach of how presenting proposals to users by %exploiting their familiarity with their own code.}

%We assume that a user understands the code they themselves have written,
%and therefore understanding the initial premise of an example is simpler. 

%\textcolor{red}{We conjecture this will help user's understand proposals faster and easier, as they are already familiar with the code the proposal is being presented in.} 



%WRITE ABOUT VSCODE EXTENSION TO WRITE JSTQL CODE, WITH VALIDATIONS, ETC.

%SOMEWHERE WRITE THAT YOU USE BABEL X

%WRITE THAT YOU IMPLEMENTED A MATCHING-AND-TRANSFORMATION ALGORITHM 

%WE EVALUATED OUR TOOL ON TWO PROPOSALS AND WE GOT THESE AND THESE RESULTS

%WRITE THAT THIS IS A FIRST STEP OF ... (SEE CONCL.)