yes
This commit is contained in:
parent
e1f27f20dc
commit
f8ceb8de30
6 changed files with 254 additions and 24 deletions
3
Sources.txt
Normal file
3
Sources.txt
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
Pipeline proposal
|
||||
https://github.com/tc39/proposal-pipeline-operator
|
||||
|
||||
BIN
build/report.pdf
BIN
build/report.pdf
Binary file not shown.
|
|
@ -1 +1,6 @@
|
|||
\chapter{Chapter 2}
|
||||
\chapter{Background}
|
||||
|
||||
\section{Proposals}
|
||||
|
||||
% Should this be moved to chapter 2?
|
||||
A proposal for EcmaScript is a suggestion for a change to the language. These changes come with a set of problems that if the proposal is included as a part of EcmaScript, those problems should be solved by utilizing the additions contained within the proposal.
|
||||
253
chapter/ch3.tex
253
chapter/ch3.tex
|
|
@ -5,28 +5,34 @@ syntactic proposals for EcmaScript.
|
|||
|
||||
\section{The core idea}
|
||||
|
||||
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-exisiting knowledge to showcase new proposals for EcmaScript. Showcasing proposals this way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal author.
|
||||
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. Showcasing proposals this way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal author.
|
||||
|
||||
% Should this be moved to chapter 2?
|
||||
A proposal for EcmaScript is a suggestion for a change to the language. These changes come with a set of problems that if the proposal is included as a part of EcmaScript, those problems should be solved by utilizing the additions contained within the proposal.
|
||||
Further in this chapter, we will be discussing the \textit{old} and \textit{new} way of programming in EcmaScript. What we are referring to in this case is with set of problems a proposal is trying to solve, if that proposal is allowed into EcmaScript as part of the language, there will be a \textit{new} way of solving said problems. The \textit{old} way is the current status quo when the proposal is not part of EcmaScript, and the \textit{new} way is when the proposal is part of EcmaScript and we are utilizing the new features of said proposal.
|
||||
|
||||
Further in this chapter, we will be discussing the \textit{old} and \textit{new} way of solving a problem. What we are referring to in this case is whatever set of problems a proposal is trying to solve, if that proposal is allowed into EcmaScript as part of the language, there will be a \textit{new} way of solving said problems. The \textit{old} way is the current status quo when the proposal is not part of EcmaScript, and the \textit{new} way is when the proposal is part of EcmaScript and we are utilizing the new features of said proposal.
|
||||
The program will allow the users to preview proposals way before they are part of the language. This way the committee will get feedback from users of the language earlier in the proposal process, this will ideally allow for a more efficient process of adding proposals to EcmaScript.
|
||||
|
||||
\section{Applying a proposal}
|
||||
\subsection{Applying a proposal}
|
||||
|
||||
The way this project will use the pre-existing knowledge the user harbors of their own code is to use it as a base, and \textit{apply} the proposal to that base.
|
||||
The way this project will use the pre-existing knowledge a user has of their own code is to use that code as base for showcasing a proposals features. Using the users own code as base requires the following steps in order to automatically implement the examples that showcase the proposal inside the context of the users own code.
|
||||
|
||||
When a proposal is \textit{applied} to a piece of code there are some main steps. A code snippet where the proposal might be used has to be identified. That same code snippet has to be transformed to use the new features the proposal implements. Then both the original and the transformed code snippet has to be showcased to the user.
|
||||
The tool has to identify where the features and additions of a proposal could have been used. This means identifying parts of the users program that use pre-existing EcmaScript features that the proposal is interacting with and trying to solve. This will then identify all the different places in the users program the proposal can be applied. This step is called \textit{matching} in the following chapters
|
||||
|
||||
Identifying a code snippet where the proposal might be utilized, the problem a proposal is solving allows us to iden
|
||||
Once the tool has matched all parts of the program that the proposal could be applied, the users code has to be transformed to use the feature/s the proposal is trying to implement. This step also includes keeping the context and functionality of the users program the same, so variables and other context related concepts have to be transferred over to the transformed code.
|
||||
|
||||
\section{Syntactic proposal}
|
||||
The output of the previous step is then a set of code pairs, where one a part of the users original code, and the second is the transformed code. The transformed code is then ideally a perfect replacement for the original user code if the proposal is part of EcmaScript. These pairs are used as examples to present to the user, presented together so the user can see their original code together with the transformed code. This allows for a direct comparison and an easier time for the user to understand the proposal.
|
||||
|
||||
A proposal for EcmaScript is a suggested change for the language, in the case of EcmaScript this comes in the form of an addition to the language, as EcmaScript does not allow for breaking changes. There are many different kinds of proposals, one such example is a Syntactic proposal
|
||||
The steps outlined in this section require some way of defining matching and transforming of code. This has to be done very precisely and accurately in order to avoid bugs. Imprecise definition of the proposal might lead to transformed code not being a direct replacement for the code it was based upon. For this we suggest two different methods, a definition written in a custom DSL \DSL and a definition written in a self-hosted way only using EcmaScript as a language as definition language. Read more about this in SECTION HERE.
|
||||
|
||||
A syntactic proposal, is a proposal that contains only changes to the syntax of a language. This means, the proposal contains either no, or very limited change to functionality, and no changes to semantics.
|
||||
\section{Applicable proposals}
|
||||
\label{sec:proposals}
|
||||
|
||||
This is an example of a very simple syntactic proposal.
|
||||
A proposal for EcmaScript is a suggested change for the language, in the case of EcmaScript this comes in the form of an addition to the language, as EcmaScript does not allow for breaking changes. There are many different kinds of proposals, this project focuses exclusively on Syntactic Proposals.
|
||||
|
||||
\subsection{Syntactic Proposals}
|
||||
|
||||
A syntactic proposal, is a proposal that contains only changes to the syntax of a language. This means, the proposal contains either no, or very limited change to functionality, and no changes to semantics. This limits the scope of proposals this project is applicable to, but it also focuses solely on some of the most challenging proposals where the users of the language might have the strongest opinions.
|
||||
|
||||
\subsection{Simple example of a syntactic proposal}
|
||||
|
||||
Consider a imaginary proposal \exProp. This proposal describes adding an optional keyword for declaring numerical variables if the expression of the declaration is a numerical literal.
|
||||
|
||||
|
|
@ -46,15 +52,230 @@ let c = 200;
|
|||
|
||||
See that in \ref{ex:proposal} the change is optional, and is not applied to the declaration of \textit{c}, but it is applied to the declaration of \textit{x}. Since the change is optional to use, and essentially is just \textit{syntax sugar}, this proposal does not make any changes to functionality or semantics, and can therefore be categorized as a syntactic proposal.
|
||||
|
||||
\subsection{Discard Bindings}
|
||||
|
||||
\section{Showcasing syntactic proposals}
|
||||
The proposal \discardBindings is classified as a Syntactic Proposal, as it contains no change to the semantics of EcmaScript. This proposal is created to allow for discarding objects when using the feature of unpacking objects/arrays on the left side of an assignment.
|
||||
|
||||
The application of a proposal on a program will then be utilized as a way of presenting the proposal to developers using EcmaScript(hereby referred to as users). If the code used for the application is already familiar to the user, we can severely limit the amount of time spent to understand the functionality of the initial code used in the application of the proposal. This allows the users more focus on the actual change presented by the proposal, which in turn might present itself in better feedback on the proposal, as well as presenting issues about the proposal earlier in the process.
|
||||
Unpacking when doing an assignment refers to assigning internal fields of an object/array directly in the assignment rather than using a temporary variable. See \ref{ex:unpackingObject} for an example of unpacking an object and \ref{ex:unpackingArr}.
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of unpacking Object}, label={ex:unpackingObject}]
|
||||
// previous
|
||||
let temp = { a:1, b:2, c:3, d:4 };
|
||||
let a = temp.a;
|
||||
let b = temp.b;
|
||||
|
||||
// unpacking
|
||||
let {a,b ...rest} = { a:1, b:2, c:3, d:4 };
|
||||
rest; // { c:3, d:4 }
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of unpacking Array}, label={ex:unpackingArr}]
|
||||
// previous
|
||||
let tempArr = [ 0, 2, 3, 4 ];
|
||||
let a = tempArr[0]; // 0
|
||||
let b = tempArr[1] // 2
|
||||
|
||||
//unpacking
|
||||
let [a, b, _1, _2] = [ 0, 2, 3, 4 ]; // a = 0, b = 2, _1 = 3, _2 = 4
|
||||
\end{lstlisting}
|
||||
|
||||
The core idea of the proposal is sometimes when using unpacking of objects/arrays one does need all parts of the
|
||||
|
||||
\subsection{Pipeline Proposal}
|
||||
|
||||
The pipeline proposal is a Syntactic proposal with no change to functionality of EcmaScript, it focuses solely on solving problems related to nesting of function calls and other expressions that allow for a topic reference.
|
||||
|
||||
The pipeline proposal aims to solve two problems with performing consecutive operations on a value. In EcmaScript there are two main styles of achieving this functionality currently. Nesting calls and chaining calls, these two come with a differing set of challenges when used.
|
||||
|
||||
Nesting calls is mainly an issue related to function calls with one or more arguments. When doing many calls in sequence the result will be a \textit{deeply nested} call expression. See in \ref{ex:deeplyNestedCall}.
|
||||
|
||||
Challenges with nested calls
|
||||
\begin{itemize}
|
||||
\item The order of calls go from right to left, which is opposite of the natural reading direction users of EcmaScript are used to
|
||||
\item When introduction functions with multiple arguments in the middle of the nested call, it is not intuitive to see what call it belongs to.
|
||||
\end{itemize}
|
||||
Benefits of nested calls
|
||||
\begin{itemize}
|
||||
\item Does not require special design thought to be used
|
||||
\end{itemize}
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of deeply nested call}, label={ex:deeplyNestedCall}]
|
||||
// Deeply nested call with single arguments
|
||||
function1(function2(function3(function4(value))));
|
||||
|
||||
// Deeply nested call with multi argument functions
|
||||
function1(function2(function3(value2, function4)), value1);
|
||||
\end{lstlisting}
|
||||
|
||||
Nesting solves some of the issues relating to nesting, as it allows for a more natural reading direction left to right when identifying the sequence of call. However, solving consecutive operations using chaining has its own set of challenges when used
|
||||
|
||||
\subsection{Description of Pipeline proposal}
|
||||
|
||||
|
||||
This showcase is done by, The user being presented with two pieces of code. One being the original version with no changes, and the other being the transformed code after, this will allow the user to see how it was written before, and see how the proposal could have been applied here. This will give a low barrier of entry to understand a proposal and give meaningful feedback to the committee.
|
||||
|
||||
This paper does not focus on showcasing and gathering user feedback, however focusing more on the process of applying a proposal to some piece of code, while maintaining its functionality.
|
||||
Challenges with chaining calls
|
||||
\begin{itemize}
|
||||
\item APIs has to be specifically designed with chaining in mind
|
||||
\item Might not even be possible due to external libraries
|
||||
\item Does not support other concepts such as arithmetic operations, array/object literals, await, yield, etc...
|
||||
\end{itemize}
|
||||
|
||||
Benefits of chaining calls
|
||||
\begin{itemize}
|
||||
\item More natural direction of call order
|
||||
\item Arguments of functions are grouped with function name
|
||||
\item Untangles deep nesting
|
||||
\end{itemize}
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of chaining calls}, label={ex:chainingCall}]
|
||||
// Chaining calls
|
||||
function1().function2().function3();
|
||||
|
||||
// Chaining calls with multiple arguments
|
||||
function1(value1).function2().function3(value2).function4();
|
||||
\end{lstlisting}
|
||||
|
||||
The pipeline proposal aims to combine the benefits of these two styles without all the challenges each method faces.
|
||||
|
||||
The main benefit of pipeline is to allow for a similar style to chaining when chaining has not been specifically designed to be applicable. The idea uses syntactic sugar to change the order of writing the calls without influencing the API of the functions.
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example from jquery}, label= {ex:pipeline}]
|
||||
// Status quo
|
||||
var minLoc = Object.keys( grunt.config( "uglify.all.files" ) )[ 0 ];
|
||||
|
||||
// With pipes
|
||||
var minLoc = grunt.config('uglify.all.files') |> Object.keys(%)[0];
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example from unpublish}, label= {ex:pipeline}]
|
||||
// Status quo
|
||||
const json = await npmFetch.json(npa(pkgs[0]).escapedName, opts);
|
||||
|
||||
// With pipes
|
||||
const json = pkgs[0] |> npa(%).escapedName |> await npmFetch.json(%, opts);
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example from underscore.js}, label= {ex:pipeline}]
|
||||
// Status quo
|
||||
return filter(obj, negate(cb(predicate)), context);
|
||||
|
||||
// With pipes
|
||||
return cb(predicate) |> _.negate(%) |> _.filter(obj, %, context);
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example from ramda.js}, label= {ex:pipeline}]
|
||||
// Status quo
|
||||
return xf['@@transducer/result'](obj[methodName](bind(xf['@@transducer/step'], xf), acc));
|
||||
|
||||
// With pipes
|
||||
return xf
|
||||
|> bind(%['@@transducer/step'], %)
|
||||
|> obj[methodName](%, acc)
|
||||
|> xf['@@transducer/result'](%);
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
\subsection{Do proposal}
|
||||
|
||||
This is where a description of the Do proposal might land
|
||||
|
||||
\subsection{Async to promises?}
|
||||
|
||||
Outline the rewriting of async to promises here
|
||||
|
||||
|
||||
|
||||
|
||||
\section{Searching user code for applicable snippets}
|
||||
|
||||
In order to identify snippets of code in the users codebase where a proposal is applicable we need some way to define patterns of code where we can apply the proposal. To do this, a DSL titled \DSL is used.
|
||||
|
||||
\section{\DSL}
|
||||
|
||||
In order to allow for the utilization of the users code. We have to identify snippets of the users code that some proposal is applicable to. In order to do this, we have designed a DSL called \DSL JavaScript Template Query Language. This DSL will contain the entire definition used to identify and transform user code in order to showcase a proposal.
|
||||
|
||||
\subsection{Identifying}
|
||||
|
||||
In order to identify snippets of code a proposal is applicable to, we use templates of JavaScript. These templates allow for \textit{wildcard} sections where it can match against specific AST nodes. These \textit{wildcard} sections are also used to transfer the context of the code matched into the transformation.
|
||||
|
||||
A template containing none of these \textit{wildcards} is matched exactly. This essentially means the match will be a direct code search for snippets where the AST of the users code match the template exactly.
|
||||
|
||||
The \textit{wildcards} are written inside a block denoted by << WILDCARD >>. Each wildcard has to have an DSL identifier, a way of referring to that wildcard in the definition of the transformation.
|
||||
|
||||
\begin{lstlisting}[caption={Example of a wildcard}, label={ex:wildcard}]
|
||||
let variableName = << expr1: CallExpression | Identifier >>;
|
||||
\end{lstlisting}
|
||||
|
||||
In \ref{ex:wildcard} a wildcard section is defined on the right hand side of an assignment statement. This wildcard will match against any AST node classified as a CallExpression or an Identifier. The DSL reuses the AST node-types from Babel.
|
||||
|
||||
\subsection{Structure of \DSL}
|
||||
|
||||
\DSL is designed to mimic the examples already provided by a proposal champion in the proposals README. These examples can be seen in each of the proposals described in \ref{sec:proposals}.
|
||||
|
||||
\subsubsection*{Define proposal}
|
||||
|
||||
The first part of \DSL is defining the proposal, this is done by creating a named block containing all definitions of templates used for matching alongside their respective transformation. This section is used to contain everything relating to a specific proposal and is meant for easy proposal identification by tooling.
|
||||
|
||||
\begin{lstlisting}[caption={Example of section containing the pipeline proposal}]
|
||||
proposal Pipeline_Proposal{
|
||||
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\subsubsection*{Defining a pair of template and transformation}
|
||||
|
||||
Each proposal will have 1 or more definitions of a template for code to identify in the users codebase, and its corresponding transformation definition. These are grouped together in order to have a simple way of identifying the corresponding pairs. This section of the proposal is defined by the keyword \textit{pair} and a block to contain its related fields. A proposal will contain 1 or more of this section. This allows for matching many different code snippets and showcasing more of the proposal than a single concept the proposal has to offer.
|
||||
|
||||
\begin{lstlisting}[caption={Example of pair section}]
|
||||
pair {
|
||||
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\subsubsection*{Template used for matching}
|
||||
|
||||
In order to define the template used to match, we have another section defined by the keyword \textit{applicable to}. This section will contain the template defined using JavaScript with specific DSL keywords defined inside the template.
|
||||
|
||||
\begin{lstlisting}[caption={Example of applicable to section}]
|
||||
applicable to {
|
||||
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\subsubsection*{Defining the transformation}
|
||||
|
||||
In order to define the transformation that is applied to a specific matched code snippet, the keyword \textit{transform to} is used. This section is similar to the template section, however it uses the specific DSL keywords to transfer the context of the matched user code, this allows us to keep parts of the users code important to the original context it was written in.
|
||||
|
||||
\begin{lstlisting}[caption={Example of transform to section}]
|
||||
transform to{
|
||||
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\subsubsection*{All sections together}
|
||||
|
||||
Taking all these parts of \DSL structure, defining a proposal in \DSL will look as follows.
|
||||
|
||||
\begin{lstlisting}[caption={\DSL definition of a proposal}]
|
||||
proposal PROPOSAL_NAME {
|
||||
pair {
|
||||
applicable to {
|
||||
|
||||
}
|
||||
transform to {
|
||||
|
||||
}
|
||||
}
|
||||
pair {
|
||||
applicable to .....
|
||||
}
|
||||
|
||||
pair ....
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\
|
||||
|
||||
|
||||
\section{\DSL}
|
||||
|
|
|
|||
|
|
@ -1,2 +1,3 @@
|
|||
\newcommand{\DSL}{DSL NAME HERE?}
|
||||
\newcommand{\exProp}{\textbf{optional let to int for declaring numerical literal variables}}
|
||||
\newcommand{\DSL}{JSTQL }
|
||||
\newcommand{\exProp}{\textbf{optional let to int for declaring numerical literal variables}}
|
||||
\newcommand{\discardBindings}{Discard Bindings}
|
||||
|
|
@ -1,22 +1,22 @@
|
|||
\RequirePackage{listings}
|
||||
\lstdefinelanguage{JavaScript}{
|
||||
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
|
||||
keywords={typeof, new, true, false, catch, function, return, null, catch, switch,let,const, var, if, in,of, while, do, else, case, break},
|
||||
keywordstyle=\color{blue}\bfseries,
|
||||
ndkeywords={class, export, boolean, throw, implements, import, this},
|
||||
ndkeywordstyle=\color{darkgray}\bfseries,
|
||||
ndkeywordstyle=\color{orange}\bfseries,
|
||||
identifierstyle=\color{black},
|
||||
sensitive=false,
|
||||
comment=[l]{//},
|
||||
morecomment=[s]{/*}{*/},
|
||||
commentstyle=\color{purple}\ttfamily,
|
||||
stringstyle=\color{red}\ttfamily,
|
||||
commentstyle=\color{gray}\ttfamily,
|
||||
stringstyle=\color{olive}\ttfamily,
|
||||
morestring=[b]',
|
||||
morestring=[b]"
|
||||
}
|
||||
|
||||
\lstset{
|
||||
language=JavaScript,
|
||||
backgroundcolor=\color{lightgray},
|
||||
backgroundcolor=\color{white},
|
||||
extendedchars=true,
|
||||
basicstyle=\footnotesize\ttfamily,
|
||||
showstringspaces=false,
|
||||
|
|
|
|||
Loading…
Reference in a new issue