finished do proposal

.vscode/settings.json

@@ -0,0 +1,9 @@
+{
+  "grammarly.files.include": [
+    "/README.md",
+    "/readme.md",
+    "/CONTRIBUTING.md",
+    "chapter/*.md",
+    "/*.tex"
+  ]
+}

chapter/ch3.tex

@@ -153,7 +153,7 @@ doWork((void, a, void, void, b) => {
 \end{lstlisting}
 
 
-The grammar of this proposal is precicely specified in the specification found in the \href{https://github.com/tc39/proposal-discard-binding?tab=readme-ov-file#object-binding-and-assignment-patterns}{proposal definition} on github. 
+The grammar of this proposal is precisely specified in the specification found in the \href{https://github.com/tc39/proposal-discard-binding?tab=readme-ov-file#object-binding-and-assignment-patterns}{proposal definition} on github. 
 
 \begin{lstlisting}[language={JavaScript}, caption={Grammar of Discard Binding}]
 var [void] = x;         // via: BindingPattern :: `void`
@@ -278,12 +278,64 @@ var minLoc = grunt.config('uglify.all.files') |> Object.keys(%)[0];
 
 \subsection{Do proposal}
 
-This is where a description of the Do proposal might land even though actually defining the do proposal will be quite difficult, as it is hard to see exactly where one can apply this LOOOOL
+The \cite[Do Proposal]{Proposal:DoProposal} is a proposal meant to bring \textit{expression oriented} programming to EcmaScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manor allowing for a highly malleable programming experience. 
+
+The motivation of the do expression proposal is to create a feature that allows for local scoping of a code block that is treated as an expression. This allows for complex code requiring multiple statements to be confined inside its own scope and the resulting value is returned from the block as an expression. Similar to how a unnamed function is used currently. The current status quo of how to achieve this behavior is to use unnamed functions and invoke them immediately, or use an arrow function, these two are equivalent to a do expression. 
+
+The codeblock of a do expression has one major difference from these equivalent functions, as it allows for implicit return of the final statement in the block. This only works if the statement does not contain a final line end (;). 
+
+The local scoping of this feature allows for a cleaner environment in the parent scope of the 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 do block. Allowing for a cleaner environment inside the parent scope where the do block is defined. 
+
+\begin{lstlisting}[language={JavaScript}, caption={Example of do expression}, label: {ex:doExpression}]
+// Current status quo
+let x = () => {
+    let tmp = f();
+    return tmp + tmp + 1;
+};
+
+// Using a immediately invoked function
+let x = function(){
+    let tmp = f();
+    return tmp + tmp + 1;
+}();
+
+// Using do expression
+let x = do {
+    let tmp = f();
+    tmp + tmp + 1
+}
+\end{lstlisting}
+
+This proposal has some limitations on its usage. Due to the implicit return of the final statement you cannot end a do expression with an \texttt{if} without and \texttt{else}, or a \texttt{loop}. 
+
 
 
 \subsection{Await to Promise}
 
-This section contains a description of a use-case of this DSL for rewriting code using the \textit{await} keyword to use a Promise in stead. 
+This section covers an imaginary proposal that was used to evaluate the program developed in this thesis. This imaginary proposal is less of a proposal and more of just a pure JavaScript transformation example. What this proposal wants to achieve is re-writing from using \texttt{await} so use promises.
+
+In order to do this an equivalent way of writing code containing \texttt{await} in the syntax of \texttt{promises} had to be identified. In this case, the equivalent way of expressing this is consuming the rest of the scope \texttt{await} was written in and place it inside a \texttt{then(() => {})} function. 
+
+\begin{lstlisting}[language={JavaScript}, caption={Example of await to promises}, label={ex:awaitToPromise}]
+// Code containing await
+
+async function a(){
+    let something = await asyncFunction();
+    let c = something + 100;
+    return c + 1;
+}
+
+// Re-written using promises
+function a(){
+    return asyncFunction().then((something) => {
+        let c = something + 100;
+        return c;
+    })
+}
+
+In the example \ref*{ex:awaitToPromise} we change \texttt{a} from async to synchronous, but we still return a promise which ensures everything using the function \texttt{a} to still get the expected value.  
+
+\end{lstlisting}
 
 \section{Searching user code for applicable snippets}
 
@@ -394,6 +446,8 @@ proposal PROPOSAL_NAME {
 
 \section{Using the \DSL with an actual syntactic proposal}
 
+In this section some examples of how a \DSL definition of each of the proposals discussed in \ref{sec:proposals} might look. These definitions do not have to cover every single case where the proposal might be applicable, as they just have to be general enough to create some amount of examples on any reasonably long code definition a user might use this tool with.  
+
 
 \subsection{Pipeline Proposal}
 
@@ -402,7 +456,7 @@ The Pipeline Proposal is the easiest to define of the proposals presented in \re
 
 \begin{lstlisting}[language={JavaScript}, caption={Example of Pipeline Proposal definition in \DSL}, label={def:pipeline}]
 proposal Pipeline{
-    pair 1 {
+    pair SingleArgument {
         applicable to {
             <<someFunctionIdent>>(<<someFunctionParam: Expression | Identifier>>);
         }
@@ -412,7 +466,7 @@ proposal Pipeline{
         }
     }
 
-    pair 2 {
+    case MultiArgument {
         applicable to {
             <<someFunctionIdent>>(
                 <<firstFunctionParam : Expression | Identifier>>, 
@@ -427,6 +481,44 @@ proposal Pipeline{
 }
 \end{lstlisting}
 
-This first pair definition of the Pipeline proposal will apply to any \textit{CallExpression} with a single parameter. And it will be applied to each of the deeply nested callExpressions. 
+This first pair definition \texttt{SingleArgument} of the Pipeline proposal will apply to any \textit{CallExpression} with a single argument. And it will be applied to each of the deeply nested callExpressions. The second pair definition \texttt{MultiArgument} will apply to any \textit{CallExpression} with 2 or more arguments. This is because we use the custom \DSL type \texttt{anyRest} that allows to match against any number of elements in an array stored on an AST node. 
 
-As can be seen in \ref{def:pipeline}
+\subsection{Do Proposal}
+
+The \cite[Do Proposal]{Proposal:DoProposal} can also be defined with this tool. This definition will never catch all the applicable sections of the users code, and is very limited in where it might discover this proposal is applicable. This is due to the Do Proposal introducing an entirely new way to write JavaScript (Expression-oriented programming). If the user running this tool has not used the current status-quo way of doing expression-oriented programming in JavaScript, \DSL will probably not find any applicable snippets in the users code. However, in a reasonably large codebase, some examples will probably be discovered. 
+
+\begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL}, label={def:DoProposal}]
+proposal DoExpression{
+    pair arrowFunction{
+        applicable to {
+            () => {
+                <<blockStatements: anyStatementList>>
+                return << returnExpr: Expr >>
+            }
+        }
+        transform to {
+            do {
+                << blockStatements >>
+                << returnExpr >>
+            }
+        }
+    }
+
+    pair immediatelyInvokedUnnamedFunction {
+        applicable to {
+            function(){
+                <<blockStatements: anyStatementList>>
+                return << returnExpr: Expr >>
+            }();
+        }
+
+        transform to {
+            do {
+                << blockStatements >>
+                << returnExpr >>
+            }
+        }
+    }
+}
+
+\end{lstlisting}

generators/commands.sty

@@ -1,3 +1,3 @@
 \newcommand{\DSL}{JSTQL }
 \newcommand{\exProp}{\textbf{optional let to int for declaring numerical literal variables}}
-\newcommand{\discardBindings}{Discard Bindings}
+\newcommand{\discardBindings}{Discard Bindings }

generators/refs.bib

@@ -8,3 +8,12 @@
   note    = {[Online; accessed 25. Apr. 2024]},
   url     = {https://github.com/tc39/proposal-discard-binding?tab=readme-ov-file#object-binding-and-assignment-patterns}
 }
+
+@misc{Proposal:DoProposal,
+  title   = {{proposal-do-expressions}},
+  journal = {GitHub},
+  year    = {2024},
+  month   = may,
+  note    = {[Online; accessed 2. May 2024]},
+  url     = {https://github.com/tc39/proposal-do-expressions}
+}