More changes done

chapter/ch2.tex

@@ -1,6 +1,53 @@
 \chapter{Background}
 
-\section{Proposals}
+\section{Technical Committee 39}
 
-% Should this be moved to chapter 2? 
+Technical Committee 39  is the committee which maintains ECMA-262~\cite{ecma262}, the language standard for ECMAScript, and other related standards. They develop this standard following the TC39 process~\cite{TC39Process} for standard extension. 
-A proposal for EcmaScript is a suggestion for a change to the language. These changes come with a set of problems that if the proposal is included as a part of EcmaScript, those problems should be solved by utilizing the additions contained within the proposal. 
+
+Technical Committee 39 (abbreviated as TC39) is a group within ECMA international, whose main goal is to develop the language standard for ECMAScript (JavaScript) and other related standards. These related standards include: ECMA-402, the internalization API of ECMA-262, ECMA-404, the standard for JSON, ECMA-414, the ECMAScript specification suite standard. The members of the committee are representatives from various companies, academic institutions, and various other organizations from all across the world interested in developing the ECMAScript language. The members are usually people working wit JavaScript engines, tooling surrounding JavaScript, and other sections related to the JavaScript language.  
+
+
+\subsection{ECMA-262 Proposals}
+
+This section will contain what is a proposal, and how proposals are developed in TC39 for the ECMA-262 language standard. 
+
+\subsection*{TC39 Process}
+
+The TC39 process~\cite{TC39Process}, is a process document describing how the extension ECMA-262 is performed. A suggested change to the ECMA-262 standard is in the form of a \emph{proposal}. This process documents describes the stages a proposal has to pass through to be accepted into the ECMA-262 standard. 
+
+Stage 0 consists if ideation. The purpose of this stage is to allow for exploration and ideation around what part of the current version of ECMAScript can be improved, and then define a problem space for the committee to focus. 
+
+Stage 1, is the point the committee has started taking the suggested addition and will consider it. The are several requirements to enter this stage: A champion has to be identified, a champion is a member TC39 who is responsible for the proposal. A rough outline of the problem, and a general shape of a solution. There has to have been discussion around key algorithms, abstractions and semantics of the proposal. Potential implementation challenges and cross-cutting concerns have to have been identified. All these described requirements have to be captured in a public repository. Once all these requirements are met, a proposal is accepted into stage 1. During this stage, the committee will work on designing a solution, and resolve any cross-cutting concerns discovered. 
+
+Stage 2, a preferred solution has been identified. Requirements for a proposal to enter this stage: All high level APIs and syntax have to be described in the proposal document. Illustrative examples of usage created. An initial specification text have to be created. In this stage, the solution identified have to be refined, minor details ironed out, and experimental implementations will be created. 
+
+Stage 2.7, the proposal is principally approved, and has to be tested and validated. To enter this stage, the major sections of the proposal have to be complete. The specification text is finished, and all reviewers of the specification have approved. Once a proposal has entered this stage, testing and validation will be performed. This is done through the prototype implementations created in stage 2, and all features of the proposal is validated. 
+
+Stage 3, proposal is recommended for implementation. Once a proposal has been sufficiently tested and verified, it is moved to stage 3. During stage 3, the proposal is implemented in all major engines. During this stage, the proposal is tested for web compatibility issues, or integration issues in the major JavaScript engines. 
+
+Stage 4, the proposal is completed and included in the standard. 
+
+At this point, the committee will devote time to examine the problem space, and discuss possible solutions. 
+
+
+
+
+Proposals - what is a proposal (has to include motivation, prior art --- see what we had in the JavaZone talk about proposals)
+
+
+
+\section{AST and Babel}
+
+
+
+Abstract Syntax Trees, Babel, AST traversal
+
+
+\section{Source code Querying}
+
+
+\section{Language Workbenches}
+
+
+
+\section{Domain Specific languages}

chapter/ch4.tex

@@ -319,37 +319,41 @@ traverse(ast, {
 
 \section{Outline of transforming user code}
 
-\begin{lstlisting}[language={JavaScript}, caption={Outline of the algorithm}, label={lst:outline}]
+\begin{algorithm}[H]
-    let wildcards = ExtractWildcards();
+    \caption{Outline of steps of algorithm}\label{lst:outline}
+\begin{algorithmic}[1]
+\State $CA, CT, W \gets extractWildcards()$
 
-    ParseWithBabel(); // Parse all JavaScript source code with Babel
+\State $A,T \gets babel.parse(CA, CT)$ \Comment{Parse templates}
+\State $C \gets babel.parse()$ \Comment{Parse user code}
 
-    MakeTrees(); // Build the tree structure from Babel AST
+\State $AT, TT, CT \gets Tree(A, T, C)$ \Comment{Build the tree structure from Babel AST}
-   
-    // Search the user code for matches to applicable to
-    if(applicableTo.program.length > 1){
-        let matches = multiStmtMatcher(codeTree, applicableTo, wildcards);
-    }else{
-        let matches = singleMatcher(codeTree, ApplicableTo, wildcards);
-    }
 
-    // Build the transformation with code matched to wildcards
+\If{$AT.length > 1$} \Comment{Decide which matcher to use}
-    for(let match of matches){
+    \State $M \gets multiMatcher(CT, AT, W)$
-        let transformed = buildTransform(match, transformTo, wildcards);
+\Else
-    }
+    \State $M \gets singleMatcher(CT, AT, W)$
+\EndIf
+
+\State $TransformedTemplates \gets $ []
+
+\For{\textbf{each} m \textbf{in} M} \Comment{Build transformation templates}
+    \State TransformedTemplates.insert $\gets$ buildTransform($m$, $TT$, $W$);
+\EndFor
+
+\For{\textbf{each} $t$ \textbf{in} TransformedTemplates} \Comment{Insert transformed templates}
+    \State traverse($C$)
+        \If{$t.node == C.node$}
+            \State $C$.replaceMany($t$);
+        \EndIf
+\EndFor
+
+\State \Return babel.generate($C$);
+
+\end{algorithmic}
+\end{algorithm}
 
-    // Replace original matched sections with transformed section 
-    for(let transform of transformed){
-        traverse(codeAST){
-            if(transform.node === codeAST.node){
-                codeAST.replace(transform);
-            }
-        }
-    }
 
-    // Generate code from the AST
-    return babel.generate(codeAST);
-\end{lstlisting}
 
 Each line in \ref{lst:outline} is a step in the full algorithm for transforming user code based on a proposal specification in our tool. These steps work as follows:
 \begin{description}

chapter/introduction.tex

@@ -2,8 +2,5 @@
 
 Intro goes here
 
-\section{Background}
 
 
-\subsection{Figures}
-

chapter/related_work.tex

@@ -1,12 +1,14 @@
 \chapter{Related Work}
 
-In this chapter, we present work related to other query languages for source code, aspect oriented programming, some code searching methods, and other JavaScript parsers. This all relates to the work described in this thesis. 
+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}
+\section*{Aspect-Oriented Programming}
 
-Aspect oriented programming, is a programming paradigm that allows for increased modularity by allowing for a high degree of separation of concerns, specifically focusing on cross-cutting concerns. Cross-cutting concerns are concerns that are present across classes and across separations within the program. 
+Aspect-oriented programming is a programming paradigm that allows for increased modularity by allowing for a high degree of separation of concerns, specifically focusing on cross-cutting concerns. 
 
-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 \textit{Advice},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. 
+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, and error handling, which are all  
+
+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 \textit{Advice},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 it performs a re-write of the code during execution to add functionality to multiple places in the executing code. 
 
@@ -61,4 +63,8 @@ Compared to Babel used in this paper, SWC focuses on speed, as its main selling
 
 \subsection*{Acorn}
 
-Acorn is another parser written in JavaScript to parser JavaScript and it's related languages. Acorn focuses on plugin support in order to support extending and redefinition on how it's internal parser works. It has a very similar syntax to and has it's own tree traversal library Acorn Walk. \cite{Babel}Babel is originally a fork of Acorn, while Babel has since had a full rewrite. Acorn focuses heavily on supporting third party plugins, which Babel does not. However Acorn was not a good fit for this project, as Acorn only supports Stage 4 proposals, and support for proposals in the early stages is a requirement. 
+Acorn is another parser written in JavaScript to parser JavaScript and it's related languages. Acorn focuses on plugin support in order to support extending and redefinition on how it's internal parser works. It has a very similar syntax to and has it's own tree traversal library Acorn Walk. \cite{Babel}Babel is originally a fork of Acorn, while Babel has since had a full rewrite. Acorn focuses heavily on supporting third party plugins, which Babel does not. However Acorn was not a good fit for this project, as Acorn only supports Stage 4 proposals, and support for proposals in the early stages is a requirement. 
+
+
+
+\section{Model-to-Model transformations}

generators/frontpage.tex

@@ -25,7 +25,8 @@
 %----------------------------------------------------------------------------------------
 
 \large \emph{Author:} Rolf Martin Glomsrud\\
-\large \emph{Supervisor:} Mikhail Barash\\[2cm]
+\large \emph{Supervisor:} Mikhail Barash\\
+\large \emph{Informal advisor:} Yulia Startsev\\[2cm]
 
 %----------------------------------------------------------------------------------------
 %   LOGO SECTION

generators/imports.sty

@@ -33,7 +33,8 @@
 \singlespacing
 \usepackage{fullpage}
 \graphicspath{{figures/}}
-
+\usepackage{algpseudocode}
+\usepackage{algorithm}
 \usepackage{listings}
 \usepackage{generators/listings-golang} 
 \usepackage{generators/listings-js}	

generators/refs.bib

@@ -384,4 +384,4 @@
   urldate = {2024-05-28},
   note    = {[Online; accessed 28. May 2024]},
   url     = {https://github.com/babel/babel/blob/main/packages/babel-parser/ast/spec.md}
-}
+}