diff --git a/build/report.pdf b/build/report.pdf index afa07fa..49d6ad9 100644 Binary files a/build/report.pdf and b/build/report.pdf differ diff --git a/chapter/ch2.tex b/chapter/ch2.tex index bd81b17..269b612 100644 --- a/chapter/ch2.tex +++ b/chapter/ch2.tex @@ -1,6 +1,53 @@ \chapter{Background} -\section{Proposals} +\section{Technical Committee 39} -% Should this be moved to chapter 2? -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. \ No newline at end of file +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. + +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} \ No newline at end of file diff --git a/chapter/ch4.tex b/chapter/ch4.tex index cc9ecb4..72846b0 100644 --- a/chapter/ch4.tex +++ b/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}] - let wildcards = ExtractWildcards(); +\begin{algorithm}[H] + \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 - - // 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); - } +\State $AT, TT, CT \gets Tree(A, T, C)$ \Comment{Build the tree structure from Babel AST} - // Build the transformation with code matched to wildcards - for(let match of matches){ - let transformed = buildTransform(match, transformTo, wildcards); - } +\If{$AT.length > 1$} \Comment{Decide which matcher to use} + \State $M \gets multiMatcher(CT, AT, W)$ +\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} diff --git a/chapter/introduction.tex b/chapter/introduction.tex index 5b7d37c..8552826 100644 --- a/chapter/introduction.tex +++ b/chapter/introduction.tex @@ -2,8 +2,5 @@ Intro goes here -\section{Background} -\subsection{Figures} - diff --git a/chapter/related_work.tex b/chapter/related_work.tex index 8e6cf25..5d1b6d2 100644 --- a/chapter/related_work.tex +++ b/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. \ No newline at end of file +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} diff --git a/generators/frontpage.tex b/generators/frontpage.tex index c7436b2..8bcf065 100644 --- a/generators/frontpage.tex +++ b/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 diff --git a/generators/imports.sty b/generators/imports.sty index 1c98351..cdb573f 100644 --- a/generators/imports.sty +++ b/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} diff --git a/generators/refs.bib b/generators/refs.bib index 6676eaa..311846a 100755 --- a/generators/refs.bib +++ b/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} -} \ No newline at end of file +}