polsevev/master
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Finished chapter 3

Browse source
This commit is contained in:
Rolf Martin Glomsrud 2024-06-01 13:27:06 +02:00
parent 378887c804
commit 5b7db8ca86
4 changed files with 56 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
build/report.pdf
View file

Binary file not shown.

81
chapter/ch3.tex
View file

@ -1,6 +1,6 @@
\chapter{Collecting User Feedback for Syntactic Proposals}
The goal for this project is to utilize user's familiarity with their own code to gain early and worthwhile feedback on a certain kind of ECMAScript proposals.
The goal for this project is to utilize users familiarity with their own code to gain early and worthwhile feedback on a certain kind of ECMAScript proposals.
\section{The core idea}
@ -27,7 +27,7 @@ The steps outlined in this section require some way of defining matching and tra
\section{Applicable proposals}
\label{sec:proposals}
A \emph{syntactic proposal} is a proposal that contains only changes to the syntax of a language. This means that the proposal contains either no or very limited change to functionality, and no changes to the semantics of the language. 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.
A \emph{syntactic proposal} is a proposal that only introduces changes to the syntax of a language. This means that the proposal assumes either no or very limited change to functionality, and no changes to the semantics of the language. This limits the scope of proposals this project is applicable to, but it also focuses solely on some of the most contentious proposals where the users of the language might have the strongest opinions.
\subsection{Simple example of a syntactic proposal}
@ -202,7 +202,7 @@ f1(v5, f2(f3(v3, f4(v1, v2)), v4), v6);
\end{minipage}\hfil
Chaining calls solves some of these issues: indeed, as it allows for a more natural reading direction left to right when identifying the sequence of call, arguments are naturally grouped together with their respective function call, and it provides a way of untangling deep nesting. However, executing consecutive operations using chaining has its own set of challenges. To use chaining, the API of the code being called has to be designed to allow for chaining. This is not always the case however, making use of chaining when it has not been specifically designed for can be very difficult. There are also concepts in JavaScript not supported when using chaining, such as arithmetic operations, literals, \texttt{await} expressions, \texttt{yield} expressions and so on. This is because all of these concepts would break the chain of calls, and one would have to use temporary variables. In the listings below are examples of both chaining with no arguments other than \texttt{self}, and examples where additional arguments are passed during the chain.
Chaining calls solves some of these issues: indeed, as it allows for a more natural reading direction left to right when identifying the sequence of call, arguments are naturally grouped together with their respective function call, and it provides a way of untangling deep nesting. However, executing consecutive operations using chaining has its own set of challenges. To use chaining, the API of the code being called has to be designed to allow for chaining. This is not always the case however, making use of chaining when it has not been specifically designed for can be very difficult. There are also concepts in JavaScript not supported when using chaining, such as arithmetic operations, literals, \texttt{await} expressions, \texttt{yield} expressions, and so on. This is because all of these concepts would break the chain of calls, and one would have to use temporary variables. In the listings below are examples of both chaining with no arguments other than \texttt{self}, and examples where additional arguments are passed during the chain.
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
@ -222,7 +222,7 @@ The ``Pipeline'' proposal aims to combine the benefits of these two styles witho
The proposal introduces a \emph{pipe operator}, which takes the result of an expression on the left, and pipes it into an expression on the right. The location of where the result is piped to is where the topic token is located. All the specifics of the exact token used as a topic token and exactly what operator will be used as the pipe operator might be subject to change, and is currently under discussion~\cite{PipelineBikeshedding}.
The code snippets below showcase the machinery of the proposal. They are the examples used to showcase the proposal in the proposal repository~\cite{Pipeline}
The code snippets below showcase the machinery of the proposal. They are the examples used to showcase the proposal in the proposal repository~\cite{Pipeline}.
The example below showcases a left to right ordering of function calls that follows the order of execution.
@ -231,13 +231,15 @@ The example below showcases a left to right ordering of function calls that foll
\begin{lstlisting}[language={JavaScript}]
// Status quo
const json = await npmFetch.json(
npa(pkgs[0]).escapedName, opts);
npa(pkgs[0]).escapedName, opts);
\end{lstlisting}
\end{minipage}\hfil
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
// With pipes
const json = pkgs[0] |> npa(%).escapedName |> await npmFetch.json(%, opts);
const json = pkgs[0]
|> npa(%).escapedName
|> await npmFetch.json(%, opts);
\end{lstlisting}
\end{minipage}\hfil
@ -246,13 +248,16 @@ In the example below, we can see that functions calls with multiple arguments ar
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
// Status quo
return filter(obj, negate(cb(predicate)), context);
return filter(
obj, negate(cb(predicate)), context);
\end{lstlisting}
\end{minipage}\hfil
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
// With pipes
return cb(predicate) |> _.negate(%) |> _.filter(obj, %, context);
return cb(predicate)
|> _.negate(%)
|> _.filter(obj, %, context);
\end{lstlisting}
\end{minipage}\hfil
@ -262,30 +267,32 @@ In the example below, we can see the topic token can be used multiple times to p
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
// Status quo
return xf['@@transducer/result'](obj[methodName](bind(xf['@@transducer/step'], xf), acc));
return xf['@@transducer/result'](
obj[methodName](bind(
xf['@@tr..'], xf), acc));
\end{lstlisting}
\end{minipage}\hfil
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
// With pipes
return xf
|> bind(%['@@transducer/step'], %)
|> bind(%['@@tr..'], %)
|> obj[methodName](%, acc)
|> xf['@@transducer/result'](%);
|> xf['@@tr..'](%);
\end{lstlisting}
\end{minipage}\hfil
The pipe operator is present in many other languages such as F\#~\cite{FPipeOperator}, Julia~\cite{JuliaPipe}, Elixir~\cite{ElixirPipe} and Unix Shell~\cite{BashPipeline}. The main difference between the these languages's pipe operator and the pipe operator suggested in this proposal is the result of the left side expression has to be piped into a function with a single argument, this proposal suggests a topic reference to be used instead, clearly marking where the left side result should be piped to. Proposals suggesting pipe expressions similar to how it is done in F\# have been rejected by TC39 multiple times, but were rejected both times due to syntactical concerns and technical challenges~\cite{PipelineHistory}
The pipe operator is present in many other languages such as F\#~\cite{FPipeOperator}, Julia~\cite{JuliaPipe}, Elixir~\cite{ElixirPipe} and Unix Shell~\cite{BashPipeline}. The main difference between the these languages pipe operator and the pipe operator suggested in this proposal is the result of the left side expression has to be piped into a function with a single argument, this proposal suggests a topic reference to be used instead, clearly marking where the left side result should be piped to. Proposals suggesting pipe expressions similar to how it is done in F\# have been rejected by TC39 multiple times, but were rejected both times due to syntactical concerns and technical challenges~\cite{PipelineHistory}.
\subsection{``Do Expression'' Proposal}
The ``Do expression''~\cite{Proposal:DoProposal} proposal is a proposal meant to bring a style of \textit{expression oriented programming}~\cite{ExpressionOriented} to ECMAScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manner, resulting in a highly malleable programming experience.
The ``Do Expression''~\cite{Proposal:DoProposal} proposal is a proposal meant to bring a style of \textit{expression oriented programming}~\cite{ExpressionOriented} to ECMAScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manner, resulting in a highly malleable programming experience.
The motivation of the ``Do expression'' proposal is to allow for local scoping of a code block that is treated as an expression. Thus, complex code requiring multiple statements will be confined inside its own scope~\cite[Sect. 8.2]{ecma262} and the resulting value is returned from the block implicitly as an expression, similarly to how unnamed functions or arrow functions are currently used. To achieve this behavior in the current version of ECMAScript, one needs to use immediately invoked; unnamed functions~\cite[Sect. 15.2]{ecma262} or arrow function~\cite[Sect. 15.3]{ecma262}.
The motivation of the ``Do Expression'' proposal is to allow for local scoping of a code block that is treated as an expression. Thus, complex code requiring multiple statements will be confined inside its own scope~\cite[Sect. 8.2]{ecma262} and the resulting value is returned from the block implicitly as an expression, similarly to how unnamed functions or arrow functions are currently used. To achieve this behavior in the current version of ECMAScript, one needs to use immediately invoked unnamed functions~\cite[Sect. 15.2]{ecma262} or immediately invoked arrow functions~\cite[Sect. 15.3]{ecma262}.
The codeblock of a \texttt{do} expression has one major difference from these equivalent functions, as it allows for implicit return of the final statement of the block, and is the resulting value of the entire \texttt{do} expression. The local scoping of this feature allows for a cleaner environment in the parent scope of the \texttt{do} expression. What is meant by this is for temporary variables and other assignments used once can be enclosed inside a limited scope within the \texttt{do} block. Allowing for a cleaner environment inside the parent scope where the \texttt{do} block is defined.
The codeblock of a \texttt{do} expression has one major difference from these equivalent functions, as it allows for implicit return of the final statement of the block, and is the resulting value of the entire \texttt{do} expression. The local scoping of this feature allows for a cleaner environment in the parent scope of the \texttt{do} expression. What is meant by this is for temporary variables and other assignments used once can be enclosed inside a limited scope within the \texttt{do} block. This allows for a cleaner environment inside the parent scope where the \texttt{do} block is defined.
The current version of JavaScript enables the use of immediately invoked arrow functions with no arguments to achieve similar behavior to ``Do expression'', an example of this can be seen in the Listing below. The main difference between immediately invoked arrow functions and ``Do expression'' is the final statement/expression will implicitly return its Completion Record~\cite[Sect. 6.2.4]{ecma262}, and we de not need a return statement.
The current version of JavaScript enables the use of immediately invoked arrow functions with no arguments to achieve similar behavior to ``Do Expression'', and an example of this can be seen in the listing below. The main difference between immediately invoked arrow functions and ``Do Expression'' is the final statement/expression will implicitly return its Completion Record~\cite[Sect. 6.2.4]{ecma262}, and thus an explicit \texttt{return} statement is not needed.
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
@ -306,7 +313,7 @@ let x = do {
\end{lstlisting}
\end{minipage}\hfil
The example below is very similar to the one above, and uses an unnamed function~\cite[15.2]{ecma262} which is invoked immediately to produce similar behavior to the ``Do expression'' proposal.
The example below is very similar to the one above, and uses an unnamed function~\cite[15.2]{ecma262} which is invoked immediately to produce similar behavior to the ``Do Expression'' proposal.
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
@ -329,9 +336,9 @@ let x = do {
\end{lstlisting}
\end{minipage}\hfil
\subsection{``Await to Promise'' (imaginary proposal)}
\subsection{``Await To Promise'' (imaginary proposal)}
We discuss now an imaginary proposal that was used as a running example during the development of this thesis. This proposal is a pure JavaScript transformation example. The transformation this proposal is meant to display is transforming code using \texttt{await}~\cite[Sect. 27.7.5.3]{ecma262} into code which uses a promise~\cite[Sect. 27.2]{ecma262}.
We discuss now an imaginary proposal that was used as a running example during the development of this thesis. This proposal demonstrates simple transformations of JavaScript code. The transformation this proposal is meant to display is transforming code using \texttt{await}~\cite[Sect. 27.7.5.3]{ecma262} into code which uses a promise~\cite[Sect. 27.2]{ecma262}.
To perform this transformation, we define an equivalent way of expressing an \texttt{await} expression as a promise. This means removing \texttt{await}, this expression now will return a promise, which has a function \texttt{then}, this function is executed when the promise resolves. We pass an arrow function as argument to \texttt{then}, and append each following statement in the current scope~\cite[Sect. 8.2]{ecma262} inside the block of that arrow function. This will result in equivalent behavior to using \texttt{await}. An example of a function using \texttt{await} can be seen below on the left. The example below on the right is the same function but is using a promise.
@ -361,7 +368,7 @@ async function a(){
\end{lstlisting}
\end{minipage}\hfil
Transforming using this imaginary proposal will result in a returning the expression present at the first \texttt{await} expression, with a deferred function \texttt{then} which will execute once the expression is completed. This function takes a callback containing a lambda function with a single argument. This argument shares a name with the initial \texttt{VariableDeclaration}. This is needed because we have to transfer all statements that occur after the original \texttt{await} expression into the body of the callback function. This callback function also has to be async, in case any of the statements placed into it contains \texttt{await}. This will result in equivalent behavior to the original code.
Transforming using this imaginary proposal will result in a returning the expression present at the first \texttt{await} expression, with a deferred function \texttt{then} which will execute once the expression is completed. This function takes a callback containing a lambda function with a single argument. This argument shares a name with the initial \texttt{VariableDeclaration}. This is needed because we have to transfer all statements that occur after the original \texttt{await} expression into the body of the callback function. This callback function also has to be declared as \texttt{async}, in case any of the statements placed into it contains \texttt{await}. This will result in equivalent behavior to the original code.
\section{Searching user code for applicable parts}
@ -370,7 +377,7 @@ To identify parts of code in the user's code where a proposal is applicable, we
\subsection{Structure of \DSL{}}
\label{sec:DSLStructure}
In this section, we describe the structure of \DSL{} (JavaScript Template Query Language).
In this section, we describe the structure of \DSL{} (JavaScript Template Query Language), that was designed and implemented by the author of this thesis.
\paragraph*{Proposal definition}
@ -415,7 +422,7 @@ transform to{
\end{lstlisting}
This transformation definition, will change any code matched to its corresponding matching definition into exactly what is defined. This means for any matches produced this code will be inserted in its place.
\paragraph*{Full definition of \DSL{}}
\paragraph*{A complete specification in \DSL{}}
Taking all these parts of \DSL{} structure, defining a proposal in \DSL{} will look as follows.
@ -442,7 +449,7 @@ proposal PROPOSAL_NAME {
This complete example of \DSL{} has two \texttt{case} blocks. Each \texttt{case} is applied one at a time to the user's code. The first case will try to find any \texttt{VariableDeclaration} statements, where the identifier is \texttt{b}, and the right side expression is a \texttt{Literal} with value 100. The second \texttt{case} will change any empty \texttt{console.log} expression, into a \texttt{console.dir} expression.
\subsection{How a match and transformation is performed}
\subsection{Matching and transforming code}
\label{sec:DSL_DEF}
To perform matching and transformation of the user's code, we first have to have some way of identifying applicable user code. These applicable code sections then have to be transformed and inserted it back into the full user code definition.
@ -462,7 +469,7 @@ The example below will allow any node with type \texttt{CallExpression} to match
<< expr: CallExpression >>
\end{lstlisting}
To make this more expressive, the type expressions use binary and unary operators. The following operators are supported: \texttt{\&\&} for logical conjunction, \texttt{||} for logical disjunction,\texttt{!} for logical negation. This makes it possible to build complex type expressions, making it very expressive exactly what nodes are allowed to match against a specific wildcard.
To make this more expressive, the type expressions use binary and unary operators. The following operators are supported: \texttt{\&\&} for logical conjunction, \texttt{||} for logical disjunction, and \texttt{!} for logical negation. This makes it possible to build complex type expressions, enabling us to express exactly what nodes are allowed to match against a specific wildcard.
In the example below on line 1, we want to limit the wildcard to not match against any nodes with type \texttt{VariableDeclaration}, while still allowing any other \texttt{Statement}. On line 2 below we want to avoid any loop-specific statements. We express this by allowing any \texttt{Statement}, but we negate the expression containing the types of loop specific statements.
\begin{lstlisting}
@ -485,7 +492,7 @@ let variableName = << expr1: ((CallExpression || Identifier) && !ReturnStatement
\end{lstlisting}
\subsection{Transforming}
\subsection{Transforming code}
When matching parts of the users code has been found, we need some way of defining how to transform those parts to showcase a proposal. This is done using the \texttt{transform to} template. This template describes the general structure of the newly transformed code.
@ -511,7 +518,7 @@ transform to {
\DSL{} is designed to closely mimic the style of the examples required in the TC39 process~\cite{TC39Process}. We chose to design it this way to specifically make this tool fit the use-case of the committee. Since the idea behind this project is to gather early user feedback on syntactic proposals, the users of this kind of til is the committee themselves, as they are the ones that want user feedback.
Writing a proposal definition in \DSL{} is done with text, most domain-specific languages have some form of tooling to make the process of using the DSL simpler and more intuitive. \DSL{} has an extension built for Visual Studio Code, see Figure \ref{fig:ExtensionExample}. This extension supports auto completion, error checking, and other common IDE features.
Writing a proposal definition in \DSL{} is done with text, most domain-specific languages have some form of tooling to make the process of using the DSL simpler and more intuitive. \DSL{} has an extension built for Visual Studio Code (see Figure \ref{fig:ExtensionExample}). This extension supports auto-completion, error checking, and other common IDE features.
\begin{figure}[H]
\begin{center}
@ -521,7 +528,7 @@ Writing a proposal definition in \DSL{} is done with text, most domain-specific
\end{center}
\end{figure}
The language server included with this extension performs validation of the wildcards. This allows verification of wildcard declarations in applicable to, as shown in Figure~\ref{fig:NoTypes}. If a wildcard is declared with no types, an error will be reported.
The language server used in this extension performs validation of the wildcards. This allows verification of wildcard declarations in applicable to, as shown in Figure~\ref{fig:NoTypes}. If a wildcard is declared with no types, an error will be reported.
\begin{figure}[H]
\begin{center}
@ -541,9 +548,9 @@ The extension automatically uses wildcard declarations in \texttt{applicable to}
\section{Using the \DSL{} with syntactic proposals}
In this section, we present specifications of the proposals described in Section~\ref{sec:proposals}. We will use these specifications to evaluate the tool created in this thesis. These specifications do not have to cover every single case where the proposal might be applicable, as they only have to be general enough to create some amount of examples that will give a representative number of matches when the transformations are applied to some relatively long user code.
In this section, we present specifications of the proposals described in Section~\ref{sec:proposals}. We will use these specifications to evaluate the tool created in this thesis. These specifications do not necessarily need to cover every single case where the proposal might be applicable, as they only have to be general enough to create some amount of examples that will give a representative number of matches when the transformations are applied to some relatively long user code.
This is because this tool is designed to be used by TC39 to gather feedback from user's on proposals during development. This use case means the specifications should be defined in a way that showcases the proposal. This also means it is important the transformation is correct, as incorrect transformations might lead to bad feedback on a proposal.
This is because this tool is designed to be used by TC39 to gather feedback from user's on proposals during development. This use case means the specifications should be defined in a way that showcases the proposal. This also means it is important that the transformation is correct, as incorrect transformations might lead to bad feedback on a proposal.
\subsection{``Pipeline'' Proposal}
@ -578,7 +585,7 @@ In the Listing \ref{def:pipeline}, the first \texttt{case} definition \texttt{Si
\subsection{``Do Expression'' Proposal}
The ``Do expression'' proposal~\cite{Proposal:DoProposal} focuses on bringing expression-oriented programming to JavaScript.
The ``Do Expression'' proposal~\cite{Proposal:DoProposal} focuses on bringing expression-oriented programming to JavaScript.
\begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL{}.}, label={def:doExpression}]
proposal DoExpression{
@ -615,15 +622,15 @@ proposal DoExpression{
}
\end{lstlisting}
In Listing \ref{def:doExpression}, the specification of ``Do expression'' proposal in \DSL{} can be seen. It has two cases: the first case \texttt{arrowFunction} applies to code using an immediately invoked arrow function~\cite[15.3]{ecma262} with a return value. The wildcard \texttt{statements} matches against one or more statements that are not of type \texttt{ReturnStatement}. The reason we limit the wildcard is we cannot match the final statement of the block to this wildcard, as that has to be matched against the return statement in the template. The second wildcard \texttt{returnVal} matches against any expressions; the reason for extracting the expression from the \texttt{return} statement, is to use it in the implicit return of the \texttt{do} block. In the transformation template, we replace the arrow function with with a \texttt{do} expression. This expression has to be defined inside parenthesis, as a free floating \texttt{do} expression is not allowed due to ambiguous parsing against a \texttt{do while} statement. We insert the statements matched against \texttt{statements} wildcard into the block of the \texttt{do} expression, and the final statement of the block is the expression matched against the \texttt{returnVal} wildcard. This will transform an arrow function into a \texttt{do} expression.
In Listing \ref{def:doExpression}, the specification of ``Do Expression'' proposal in \DSL{} can be seen. It has two cases: the first case \texttt{arrowFunction} applies to code using an immediately invoked arrow function~\cite[15.3]{ecma262} with a return value. The wildcard \texttt{statements} matches against one or more statements that are not of type \texttt{ReturnStatement}. The reason we limit the wildcard is we cannot match the final statement of the block to this wildcard, as that has to be matched against the return statement in the template. The second wildcard \texttt{returnVal} matches against any expressions; the reason for extracting the expression from the \texttt{return} statement, is to use it in the implicit return of the \texttt{do} block. In the transformation template, we replace the arrow function with with a \texttt{do} expression. This expression has to be defined inside parenthesis, as a free floating \texttt{do} expression is not allowed due to ambiguous parsing against a \texttt{do while} statement. We insert the statements matched against \texttt{statements} wildcard into the block of the \texttt{do} expression, and the final statement of the block is the expression matched against the \texttt{returnVal} wildcard. This will transform an arrow function into a \texttt{do} expression.
The second case \texttt{unnamedFunction} follows the same principle as the first case, but is applied to immediately invoked unnamed functions, and produces the exact same output after the transformation as the first case. This is because immediately invoked unnamed functions are equivalent to arrow functions.
\subsection{`Await to promise'' imaginary proposal}
\subsection{``Await to promise'' imaginary proposal}
\begin{lstlisting}[language={JavaScript}, caption={Definition of ``Await to promise'' evaluation proposal in \DSL{}.}, label={def:awaitToPromise}]
proposal awaitToPomise{
\begin{lstlisting}[language={JavaScript}, caption={Definition of ``Await To Promise'' evaluation proposal in \DSL{}.}, label={def:awaitToPromise}]
proposal awaitToPromise{
case single{
applicable to {
"let <<ident:Identifier>> = await <<awaitedExpr: Expression>>;
@ -642,9 +649,9 @@ proposal awaitToPomise{
}
\end{lstlisting}
The specification of ``Await to promise'' in \DSL{} is created to match asynchronous code inside a function. It is limited to match asynchronous functions containing a single await statement, and that await statement has to be stored in a \texttt{VariableDeclaration}. The second wildcard \texttt{statements} is designed to match all statements following the \texttt{await} statement up to the return statement. This is done to move the statements into the callback function of \texttt{then()} in the transformation. We include \texttt{\!ReturnStatement} because we do not want to consume the return as it would then be removed from the functions scope and into the callback function of \texttt{then()}. We also have to avoid matching where there exists loop specific statements such as \texttt{ContinueStatement} or \texttt{BreakStatement}.
The specification of ``Await To Promise'' in \DSL{} is specified to match asynchronous code inside a function. It is limited to match asynchronous functions containing a single await statement, and that await statement has to be stored in a \texttt{VariableDeclaration}. The second wildcard \texttt{statements} is designed to match all statements following the \texttt{await} statement up to the return statement. This is done to move the statements into the callback function of \texttt{then()} in the transformation. We include \texttt{\!ReturnStatement} because we do not want to consume the return as it would then be removed from the functions scope and into the callback function of \texttt{then()}. We also have to avoid matching where there exists loop specific statements such as \texttt{ContinueStatement} or \texttt{BreakStatement}.
The transformation definition has to use an async arrow function as argument for \texttt{then}, as there might be more await expressions contained within \texttt{statements}.
The transformation definition has to use an \texttt{async} arrow function as argument for \texttt{then}, as there might be more await expressions contained within \texttt{statements}.
\section{\DSL{}-SH}
@ -656,7 +663,7 @@ The templates are defined in a similar manner to \DSL{}, however one does not wr
In the example below is the first \texttt{case} of the ``Pipeline'' proposal defined using \DSL{}-SH JavaScript object. We define the wildcards in the object key \texttt{prelude}, where it is defined as valid JavaScript. The variable declarations define the wildcards, and we use the variables defined to reference wildcards in the templates.
\begin{lstlisting}[language={JavaScript}]
// Equivalent definition in JSTQL-SH
// Equivalent definition of pipeline first case in JSTQL-SH
{
prelude: `
let someFunctionIdent = "Identifier || MemberExpression";

6
chapter/ch5.tex
View file

@ -42,7 +42,7 @@ The imaginary ``Await to promise'' proposal also has an expected number of match
\textbf{Three.js}~\cite{ThreeJS} is a library for 3D rendering in JavaScript. It is written purely in JavaScript and uses GPU for 3D calculations. It being a popular JavaScript library, and being written in mostly pure JavaScript makes it a good case study for our tool. It currently sits at over 1 million downloads weekly.
\textbf{Three.js}~\cite{ThreeJS} is a library for 3D rendering in JavaScript. It is written purely in JavaScript and uses GPU for 3D calculations. It being a popular JavaScript library, and being written in mostly pure JavaScript, makes it a good case study for our tool.
\begin{table}[H]
\begin{center}
@ -62,7 +62,7 @@ The imaginary ``Await to promise'' proposal also has an expected number of match
\label{fig:evalThreeJS}
\end{table}
\textbf{React}~\cite{React} is a graphical user interface library for JavaScript, it facilitates the creation of user interfaces for both web and native platforms. React is based upon splitting a user interface into components for simple development. It is currently one of the most popular libraries for creating web apps and has over 223000 stars on Github.
\textbf{React}~\cite{React} is a graphical user interface library for JavaScript, it facilitates the creation of user interfaces for both web and native platforms. React is based upon splitting a user interface into components for simple development. It is currently one of the most popular libraries for creating web apps.
\begin{table}[H]
\begin{center}
@ -83,7 +83,7 @@ The imaginary ``Await to promise'' proposal also has an expected number of match
\end{table}
\textbf{Bootstrap}~\cite{Bootstrap} is a front-end framework used for creating responsive and mobile-first websites, it comes with a variety of built-in components, as well as a built in styling. This styling is also customizable using CSS. This library is a good evaluation point for this thesis as it is written in pure JavaScript and is used by millions of developers.
\textbf{Bootstrap}~\cite{Bootstrap} is a front-end framework used for creating responsive and mobile-first websites, it comes with a variety of built-in components, as well as a built in styling. This styling is also customizable using CSS. This library is a good evaluation point for this thesis as it is written in pure JavaScript.
\begin{table}[H]
\begin{center}

20
chapter/related_work.tex
View file

@ -2,16 +2,6 @@
In this chapter, we present work related to other query languages for source code, aspect-oriented programming, some code querying methods, and other JavaScript parsers. This all relates to the work described in this thesis.
\section{Aspect-Oriented Programming}
AoP, is a programming paradigm that gives increased modularity by allowing for a high degree of separation of concerns, specifically focusing on cross-cutting concerns.
Cross-cutting concerns are aspects of a software program or system that have an effect at multiple levels, cutting across the main functional requirements. Such aspects are often related to security, logging, or error handling, but could be any concern that are shared across an application.
In AOP, one creates an \textit{aspect}, which is a module that contains some cross-cutting concern the developer wants to achieve, this can be logging, error handling or other concerns not related to the original classes it should applied to. An aspect contains advices,which is the specific code executed when certain conditions of the program are met, an example of these are \textit{before advice}, which is executed before a method executes, \textit{after advice}, which is executed after a method regardless of the methods outcome, and \textit{around advice}, which surrounds a method execution. Contained within the aspect is also a \textit{pointcut}, which is the set of criteria determining when the aspect is meant to be executed. This can be at specific methods, or when specific constructors are called etc.
Aspect oriented programming is similar to this project in that to define where \textit{pointcuts} are placed, we have to define some structure and the AOP library has to search the code execution for events triggering the pointcut and run the advice defined within the aspect of that given pointcut. Essentially performing a rewrite of the code during execution to add functionality to multiple places in the executing code.
\section{Other source code query languages}
To allow for simple analysis and refactoring of code, there exists many query languages designed to query source code. These languages use several methods to allow for querying code based on specific paradigms such as logical queries, declarative queries, or SQL-like queries. All provide similar functionality of being able to query code. In this section we will look some of these languages for querying source code, and how they relate to \DSL{} developed in this thesis.
@ -114,5 +104,13 @@ Model-to-Model transformations are a part of model-driven engineering (MDE). The
The process of performing a model-to-model transformation is to convert one model into another, while preserving or adapting its underlying semantics and structure~\cite{ModelToModelTransformations}. This is usually done by traversing its structure, and extracting data and transforming its format to fit the model it should be transformed into. This allows a model described within one domain to be transformed into another automatically.
This is quite similar to what our tool described in this thesis is doing. We are transforming the AST of the user code from one AST definition not using a proposal, so one form of representation, into another using a proposal not part of the original AST.
\section{Aspect-Oriented Programming}
AOP, is a programming paradigm that enables modularity by allowing for a high degree of separation of concerns, specifically focusing on cross-cutting concerns. cross-cutting concerns are aspects of a software program or system that have an effect at multiple levels, cutting across the main functional requirements. Such aspects are often related to security, logging, or error handling, but could be any concern that are shared across an application.
In AOP, one creates an \textit{aspect}, which is a module that contains some cross-cutting concern the developer wants to achieve, this can be logging, error handling or other concerns not related to the original classes it should applied to. An aspect contains advices,which is the specific code executed when certain conditions of the program are met, an example of these are \textit{before advice}, which is executed before a method executes, \textit{after advice}, which is executed after a method regardless of the methods outcome, and \textit{around advice}, which surrounds a method execution. Contained within the aspect is also a \textit{pointcut}, which is the set of criteria determining when the aspect is meant to be executed. This can be at specific methods, or when specific constructors are called etc.
Aspect oriented programming is similar to this project in that to define where \textit{pointcuts} are placed, we have to define some structure and the AOP library has to search the code execution for events triggering the pointcut and run the advice defined within the aspect of that given pointcut. Essentially performing a rewrite of the code during execution to add functionality to multiple places in the executing code.
This is quite similar to what our tool described in this thesis is doing. We are transforming the AST of the user code from one AST definition not using a proposal, so one form of representation, into another using a proposal not part of the original AST.