added exampels of extension to ch3

chapter/ch3.tex

@@ -483,20 +483,23 @@ transform to {
 \end{lstlisting}
 
 
-\subsection{Who are the users of \DSL}
+\subsection{Using \DSL}
 
 \DSL is designed to be used in tandem with proposal development, this means the users of \DSL will most likely be contributors to TC39\cite{TC39} or member of TC39. 
 
 \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. The idea behind this project is to gather early user feedback on syntactic proposals, this would mean the main users of this kind of tool is the committee themselves. 
 
-\DSL is just written using text, most modern Domain-specific languages have some form of tooling in order to make the process of using the DSL simpler and more intuitive. \DSL has an extension built for Visual Studio Code, this extension supports auto complete on each of the fields, such as \texttt{case} or \texttt{applicable to}, it will produce errors if fields are defined wrong or missing parameters.  The extension also performs error checking on the wildcards, such as checking for wildcards with missing type parameters, or wrong expression definitions. An example of how writing \DSL with the extension enabled looks can be seen in Figure \ref*{fig:ExtensionExample}. 
+\DSL is just written using text, most modern Domain-specific languages have some form of tooling in order 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 many common features of language servers, it supports auto completion, it will produce errors if fields are defined wrong or missing parameters. The extension performs validation of the wildcards, such as checking for wildcards with missing type parameters,wrong expression definitions, or usage of undeclared wildcards, a demonstration of this can be seen in \ref{fig:ExtensionError}. 
 
 \begin{figure}[H]
     \includegraphics[width=\textwidth]{figures/ExtensionExample.png}
-    \label{fig:ExtensionExample}
+    \caption{\label{fig:ExtensionExample} Writing \DSL in Visual Studio Code with extension}
-    \caption{Writing \DSL in Visual Studio Code with extension}
 \end{figure}
 
+\begin{figure}[H]
+    \includegraphics[width=\textwidth]{figures/ErrorExampleExtension.png}
+    \caption{\label{fig:ExtensionError} Errors of wildcards}
+\end{figure}
 
 \section{Using the \DSL with syntactic proposals}
 
@@ -504,7 +507,7 @@ This section contains the definitions of the proposals used to evaluate the tool
 
 \subsection{"Pipeline" Proposal}
 
-The Pipeline proposal is the first we define of the proposals presented in Section \ref*{sec:proposals}. This is due to the proposal being applicable to function calls, which is used all across JavaScript. This proposal is trying to solve readability when performing deeply nested function calls. 
+The Pipeline proposal is the first we define of the proposals presented in Section \ref{sec:proposals}. This is due to the proposal being applicable to function calls, which is used all across JavaScript. This proposal is trying to solve readability when performing deeply nested function calls. 
 
 
 \begin{lstlisting}[language={JavaScript}, caption={Example of Pipeline Proposal definition in \DSL}, label={def:pipeline}]
@@ -531,7 +534,7 @@ proposal Pipeline {
 }
 \end{lstlisting}
 
-In the Listing \ref*{def:pipeline}, the first pair definition \texttt{SingleArgument} will apply to any \textit{CallExpression} with a single argument. We do not expressively write a \texttt{CallExpression} inside a wildcard, as we have defined the structure of a \texttt{CallExpression}. The first wildcard \texttt{someFunctionIdent}, has the types of \texttt{Identifier}, to match against single identifiers, and \texttt{MemberExpression}, to match against functions who are members of objects, i.e. \texttt{console.log}. In the transformation template, we define the structure of a function call using the pipe operator, but the wildcards change order, so the argument passed as argument \texttt{someFunctionParam} is placed on the left side of the pipe operator, and the \texttt{CallExpression} is on the right, with the topic token as the argument. This case will produce a match against all function calls with a single argument, and transform them to use the pipe operator. The main difference of the second case \texttt{TwoArgument}, is it matches against functions with exactly two arguments, and uses the first argument as the left side of the pipe operator, while the second argument remains in the function call. 
+In the Listing \ref{def:pipeline}, the first pair definition \texttt{SingleArgument} will apply to any \textit{CallExpression} with a single argument. We do not expressively write a \texttt{CallExpression} inside a wildcard, as we have defined the structure of a \texttt{CallExpression}. The first wildcard \texttt{someFunctionIdent}, has the types of \texttt{Identifier}, to match against single identifiers, and \texttt{MemberExpression}, to match against functions who are members of objects, i.e. \texttt{console.log}. In the transformation template, we define the structure of a function call using the pipe operator, but the wildcards change order, so the argument passed as argument \texttt{someFunctionParam} is placed on the left side of the pipe operator, and the \texttt{CallExpression} is on the right, with the topic token as the argument. This case will produce a match against all function calls with a single argument, and transform them to use the pipe operator. The main difference of the second case \texttt{TwoArgument}, is it matches against functions with exactly two arguments, and uses the first argument as the left side of the pipe operator, while the second argument remains in the function call. 
 
 
 \subsection{"Do Expressions" Proposal}
@@ -574,7 +577,7 @@ 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 a code snippet using an arrow function\cite{ArrowFunction} with a return value. The wildcards of this template are \texttt{statements}, which is a wildcard that matches against one or more statements that are not of type \texttt{ReturnStatement}, the reason we limit the one or more match 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 do expression has to be defined inside parenthesis, as a free floating do expression is not allowed due to ambiguous parsing against a \texttt{do {} while()} statement. We and 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 produce an equivalent transformation of an arrow function into a \texttt{do} expression. The second case \texttt{immediatelyInvokedAnonymousFunction} follows the same principle as the first case, but is applied to immediately invoked anonymous functions, and produces the exact same output after the transformation as the first case. This is because immediately invoked anonymous functions are equivalent to arrow functions. 
+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 a code snippet using an arrow function\cite{ArrowFunction} with a return value. The wildcards of this template are \texttt{statements}, which is a wildcard that matches against one or more statements that are not of type \texttt{ReturnStatement}, the reason we limit the one or more match 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 do expression has to be defined inside parenthesis, as a free floating do expression is not allowed due to ambiguous parsing against a \texttt{do {} while()} statement. We and 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 produce an equivalent transformation of an arrow function into a \texttt{do} expression. The second case \texttt{immediatelyInvokedAnonymousFunction} follows the same principle as the first case, but is applied to immediately invoked anonymous functions, and produces the exact same output after the transformation as the first case. This is because immediately invoked anonymous functions are equivalent to arrow functions. 
 
 
 \subsection{"Await to Promise" imaginary proposal}

chapter/ch4.tex

@@ -2,9 +2,9 @@
 
 In this chapter, the implementation of the tool utilizing the \DSL and \DSLSH will be presented. It will describe the overall architecture of the tool, the flow of data throughout, and how the different stages of transforming user code are completed. 
 
-\section{Architecture}
+\section{Architecture of the solution}
 
-The architecture of the work described in this thesis is illustrated in \figFull[fig:architecture]
+The architecture of the solution described in this thesis is illustrated in \figFull[fig:architecture]
 
 In this tool, there exists two multiple ways to define a proposal, and each provide the same functionality, they only differ in syntax and writing-method. One can either write the definition in \DSL which utilizes Langium to parse the language, or one can use a JSON definition, which is more friendly as an API or people more familiar with JSON definitions.