added screenshot of extension and a section on who are the users of DSL

.vscode/notes/background.txt

@@ -0,0 +1,5 @@
+Domain specific languages (See simens thesis)
+Language workbenches
+TC39 and TC39 process ECMA-262
+proposals - what is it? (full list of requirements for a proposal)
+

chapter/ch3.tex

@@ -438,7 +438,6 @@ proposal PROPOSAL_NAME {
     }
 }
 \end{lstlisting}
-
 \subsection{\DSL}
 \label{sec:DSL_DEF}
 
@@ -469,6 +468,7 @@ When matching sections of the users code has been found, we need some way of def
 A transformation template is used to define how the matches will be transformed after applicable code has been found. The transformation is a general template of the code once the match is replaced in the original AST. However, without transferring over the context from the match, this would be a template search and replace. Thus, in order to transfer the context from the match, wildcards are defined in this template as well. These wildcards use the same block notation found in the \texttt{applicable to} template, however they do not need to contain the types, as those are not needed in the transformation. The only required field of the wildcard is the identifier defined in \texttt{applicable to}. This is done in order to know which wildcard match we are taking the context from, and where to place it in the transformation template.  
 
 
+
 Transforming a variable declaration from using \texttt{let} to use \texttt{const}.
 \begin{lstlisting}[language={JavaScript}]
 // Example applicable to template
@@ -483,6 +483,19 @@ transform to {
 \end{lstlisting}
 
 
+\subsection{Who are the users of \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}. 
+
+\begin{figure}[H]
+    \includegraphics[width=\textwidth]{figures/ExtensionExample.png}
+    \label{fig:ExtensionExample}
+    \caption{Writing \DSL in Visual Studio Code with extension}
+\end{figure}
 
 
 \section{Using the \DSL with syntactic proposals}
@@ -564,14 +577,14 @@ proposal DoExpression {
 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 Promises evaluation proposal}
+\subsection{"Await to Promise" imaginary proposal}
 
-This section will cover the evaluation proposal we created in order to evaluate this tool described in \ref{sec:proposals}. 
+The imaginary proposal "Await to Promise" is created to transform code snippets from using \texttt{await}, to use a promise with equivalent functionality.  
 
-This proposal was created in order to evaluate the tool, as it is quite difficult to define applicable code in this current template form. This definition is limited, and can only apply if the function only contains a single await expression. This actually highlights some of the issues with the current design of \DSL that will be described in Future Work. 
+This proposal was created in order to evaluate the tool, as it is quite difficult to define applicable code in this current template form. This definition is designed to create matches in code using await, and highlight how await could be written using a promise in stead. This actually highlights some of the issues with the current design of \DSL that will be described in Future Work. 
 
 \begin{lstlisting}[language={JavaScript}, caption={Definition of Await to Promise evaluation proposal in \DSL}, label={def:awaitToPromise}]
-proposal awaitToPomise{
+proposal awaitToPromise {
     case single{
         applicable to {
             "let <<ident:Identifier>> = await <<awaitedExpr: Expression>>;
@@ -590,6 +603,8 @@ 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. 
+
 \section{\DSLSH}
 
 In this thesis, we also created an alternative way of defining proposals and their respective transformations, this is done using JavaScript as it's own meta language for the definitions. The reason for creating a way of defining proposals using JavaScript is, it allows us to limit the amount of dependencies of the tool, since we no longer rely on \DSL, and it allows for more exploration in the future work of this project. 

generators/refs.bib

@@ -389,4 +389,13 @@
   urldate = {2024-05-25},
   note    = {[Online; accessed 25. May 2024]},
   url     = {https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-arrow-function-definitions}
+}
+
+@misc{TC39,
+  title   = {{TC39 - Specifying JavaScript.}},
+  year    = {2024},
+  month   = may,
+  urldate = {2024-05-26},
+  note    = {[Online; accessed 26. May 2024]},
+  url     = {https://tc39.es}
 }