almost finished ch3

chapter/ch3.tex

@@ -54,6 +54,7 @@ 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. 
 
+\iffalse
 \subsection{\cite{Proposal:DiscardBindings}{Discard Bindings}}
 
 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 whole idea of this proposal is to avoid declaring unused temporary variables.  
@@ -182,7 +183,7 @@ await using void = x;   // via: LexicalBinding : `void` Initializer
 ({x:void} = x);         // via: DestructuringAssignmentTarget : `void`
 \end{lstlisting}
 
-
+\fi
 \subsection{Pipeline Proposal}
 
 The Pipeline proposal \cite{Pipeline} is a syntactic proposal which focuses on solving problems related to nesting of function calls and other expressions that take an expression as an argument. 
@@ -525,41 +526,42 @@ In the Listing \ref*{def:pipeline}, the first pair definition \texttt{SingleArgu
 The "Do Expressions" proposal\cite{Proposal:DoProposal} can be specified in our tool. Due to the nature of the proposal, it is not as applicable as the "Pipeline" proposal, as it does not re-define a style that is used quite as frequently as call expressions. This means the amount of transformed code snippets this specification in \DSL will be able to perform is expected to be lower. This is due to the Do Proposal introducing an entirely new way to write expression-oriented code in JavaScript. If the user running this tool has not used the current way of writing in an expression-oriented style in JavaScript, \DSL is limited in the amount of transformations it can perform. Nevertheless, if the user has been using an expression-oriented style, \DSL will transform parts of the code.  
 
 \begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL}, label={def:doExpression}]
-proposal DoExpression{
+proposal DoExpression {
-    case arrowFunction{
+    case arrowFunction {
         applicable to {
-            "let <<ident:Identifier>> = () => {
+            "() => {
-                <<statements: (Statement && !ReturnStatement)*>>
+                <<statements: (Statement && !ReturnStatement)+>>
                 return <<returnVal : Expression>>;
             }
             "
         }
         transform to {
-            "let <<ident>> = do {
+            "(do {
                 <<statements>>
                 <<returnVal>>
-            }"
+            })"
         }
     }
 
-    case immediatelyInvokedUnnamedFunction {
+    case immediatelyInvokedAnonymousFunction {
         applicable to {
-            "let <<ident:Identifier>> = function(){
+            "(function(){
-                <<statements: (Statement && !ReturnStatement)*>>
+                <<statements: (Statement && !ReturnStatement)+>>
                 return <<returnVal : Expression>>;
-            }();"
+            })();"
         }
 
         transform to {
-            "let <<ident>> = do {
+            "(do {
                 <<statements>>
                 <<returnVal>>
-            }"
+            })"
         }
     }
 }
 \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. 
 
 
 \subsection{Await to Promises evaluation proposal}

generators/refs.bib

@@ -381,4 +381,12 @@
   urldate = {2024-05-24},
   note    = {[Online; accessed 24. May 2024]},
   url     = {https://tc39.es/process-document}
+}
+@misc{ArrowFunction,
+  title   = {{ECMAScript{\ifmmode\circledR\else\textregistered\fi} 2025 Language Specification}},
+  year    = {2024},
+  month   = may,
+  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}
 }