Added related_work and future_work

chapter/background.tex

@@ -1 +0,0 @@
-NEED TO DISCUSS SYNTACTIC SUGAR IN OTHER languages

chapter/ch3.tex

@@ -470,6 +470,38 @@ proposal PROPOSAL_NAME {
 }
 \end{lstlisting}
 
+\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. 
+
+\DSLSH is less of an actual language, and more of a program API at the moment, it allows for defining proposals purely in JavaScript objects, which is meant to allow a more modular way of using this idea. In \DSLSH you define a \textit{prelude}, which is just a list of variable declarations that contain the type expression as a string for that given wildcard. This means we do not need to perform wildcard extraction when wanting to parse the templates used for matching and transformation. 
+
+\noindent\begin{minipage}{.45\textwidth}
+\begin{lstlisting}
+// Definition in JSTQL
+proposal a{
+    case {
+        applicable to {
+            <<a:Expression>>
+        }
+        transform to {
+            () => <<a>>
+        }
+    }
+}
+\end{lstlisting}
+\end{minipage}\hfil
+\noindent\begin{minipage}{.45\textwidth}
+\begin{lstlisting}[language={JavaScript}]
+// Equivalent definition in JSTQL-SH
+{
+    prelude: 'let a = "Expression"'`,
+    applicableTo: "a;",
+    transformTo: "() => a;"
+}
+\end{lstlisting}
+\end{minipage}\hfil
+
 
 \section{Using the \DSL with an actual syntactic proposal}
 

chapter/ch4.tex

@@ -193,9 +193,9 @@ export function parseInternal(code: string): InternalParseResult {
 
 Once a wildcard has been extracted from the \texttt{pair} definitions inside \DSL, they have to be parsed into a simple Tree to be used when matching against the wildcard. This is accomplished by using a simple tokenizer and a \cite{RecursiveDescent}{Recursive Descent Parser}. 
 
-Our tokenizer simply takes the raw stream of input characters extracted from the wildcard block within the template, and determines which part is what token. Due to the very simple nature of the type expressions, no ambiguity is present with the tokens, so determining what token is meant to come at what time is quite trivial. The tokenizer \textbf{I need to figure out what kind of tokenization algorithm i am actually using LOL}
+Our tokenizer simply takes the raw stream of input characters extracted from the wildcard block within the template, and determines which part is what token. Due to the very simple nature of the type expressions, no ambiguity is present with the tokens, so determining what token is meant to come at what time is quite trivial. We simply use a switch case on the current token, if the token is of length 1 we simply accept it and move on to the next character. If the next character is an unexpected one it will produce an error. The tokenizer also groups tokens with a \textit{token type}, this allows for an easier time parsing the tokens later. 
 
-A recursive descent parser is created to closely mimic the grammar of the language the parser is implemented for, where we define functions for handling each of the non-terminals and ways to determine what non terminal each of the tokens result in. In the case of this parser, the language is a very simple boolean expression language. We use boolean combinatorics to determine whether or not a specific AST nodetype of a \cite{BabelParser}{Babel parser} AST node is a match against a specific wildcard. This means we have to create a very simple AST that can be evaluated using the AST nodetype as an input. 
+A recursive descent parser is created to closely mimic the grammar of the language the parser is implemented for, where we define functions for handling each of the non-terminals and ways to determine what non terminal each of the token-types result in. In the case of this parser, the language is a very simple boolean expression language. 
 
 \begin{lstlisting}[caption={Grammar of type expressions}, label={ex:grammarTypeExpr}]
 Wildcard:
@@ -233,9 +233,11 @@ Our recursive descent parser produces a very simple \cite{AST1,AST2}{AST} which
 
 The self-hosted version \DSLSH also requires some form of pre-parsing in order to prepare the internal DSL environment. This is relatively minor and only parsing directly with no insertion compared to \DSL. 
 
-In order to use JavaScript as the meta language to define JavaScript we define a \texttt{Prelude}. This prelude is required to consist of several \texttt{Declaration Statements} where the variable names are used as the internal DSL variables and right side expressions are used as the DSL types. In order to allow for multiple types to be allowed for a single internal DSL variable we re-use JavaScripts list definition. 
+In order to use JavaScript as the meta language to define JavaScript we define a \texttt{Prelude}. This prelude is required to consist of several \texttt{Declaration Statements} where the variable names are used as the internal DSL variables and right side expressions are strings that contain the type expression used to determine a match for that specific wildcard.
 
-We use Babel to generate the AST of the \texttt{prelude} definition, this allows us to get a JavaScript object structure. Since the structure is very strictly defined, we can expect every \texttt{stmt} of \texttt{stmts} to be a variable declaration, otherwise throw an error for invalid prelude. Continuing through the object we have to determine if the prelude definition supports multiple types, that is if it is either an \texttt{ArrayDeclaration} or just an \texttt{Identifier}. If it is an array we initialize the prelude with the name field of the \texttt{VariableDeclaration} to either an empty array and fill it with each element of the ArrayDeclaration or directly insert the single Identifier. 
+We use Babel to generate the AST of the \texttt{prelude} definition, this allows us to get a JavaScript object structure. Since the structure is very strictly defined, we can expect every \texttt{stmt} of \texttt{stmts} to be a variable declaration, otherwise throw an error for invalid prelude. Then the string value of each of the variable declarations is passed to the same parser used for \DSL wildcards. 
+
+The reason this is preferred is it allows us to avoid having to extract the wildcards and inserting an Identifier. 
 
 \section{Using Babel to parse}
 \label{sec:BabelParse}

chapter/comments

@@ -1,2 +0,0 @@
-MOve order -> Simple -> Await -> Pipeline -> Do proposal -> Discard bindings
-

chapter/future_work.tex

@@ -0,0 +1,12 @@
+\chapter{Future Work}
+
+\textbf{Provide access and gather feedback}. This project is build upon creating a tool for users of EcmaScript to see new proposals within their own codebase. The idea behind this is to use the users familiarity to showcase new syntactic proposals, and get valuable feedback to the committee developing the ECMA-262 standard. This means making the definitions of a proposal in \DSL and this tool available to end-users to execute using their own code. This can come in multiple forms, we suggest some ideas, such as a playground on the web, an extension for Visual Studio Code, or to be used in github pull requests. 
+
+\textbf{Supporting other languages}. The idea of showcasing changes to a programming language by transforming user code is not only limited to EcmaScript, and could be applied to many other programming languages using a similar developement method to EcmaScript. The developers of a language could write definitions of new changes for their respective language, and use a similar tool to the one discussed in this thesis to showcase possible new changes. 
+
+\textbf{Parameterized specifications}. The current form of \DSL supports writing each template as its own respective case, but multiple templates might be very similar and could be written using generics that are shared between case definitions. Introducing this might give a simpler way of writing more complex definitions of a proposal transformation by re-using generic type parameters for the wildcards used in the transformations. 
+
+\textbf{Fully self-hosting \DSLSH}. The current version of \DSLSH relies on this tools parser to generate the AST for the type expressions used for matching by wildcards. This might make this tool more difficult to adopt for the committee. Therefore adding functionality for writing these type expressions purely in JavaScript and allowing for the use of JavaScript as its own meta language is an interesting avenue to explore. 
+
+\textbf{Support for custom proposal syntax}. Currently this tool relies heavily on that a proposal is supported by \cite{Babel}{Babel}. This makes the tool quite limited in what proposals could be defined and transformed due to relying on Babel for parsing the templates and generating the output code. Introducing some way of defining new syntax for a proposal in the proposal definition, and allowing for parsing JavaScript containing that specific new syntax would limit the reliance on Babel, and allow for defining proposals earlier in the development process. This can possibly be done by implementing a custom parser inside this tool that allows defining custom syntax for specific new proposals. 
+

chapter/related_work.tex

@@ -0,0 +1,42 @@
+\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. 
+
+\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. 
+
+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. 
+
+\section*{Other code-query languages}
+
+In order to allow for simple analysis and refactoring of code, there already exists query languages for querying code. These languages use several methods to allow for querying code based on specific paradigms such as Logical queries, Declarative queries, or SQL like queries. All provide similar functionality of being able to query code. In this section we will look at three different languages for querying Java code, and their approach to searching code. 
+
+\subsection*{Browse-By-Query}
+
+Browse-By-Query is a language created for Java that analyses Java Bytecode files, and builds a database structure to represent the code classes, method calls, and other sections contained within the code. The language uses english-like queries combined with filtering and set operators to allow for more complex queries. This language was created as a way to browse large code-bases like one is browsing a database. Since BBQ builds the source code into something resembling a database, queries can be done with respect to each objects relationship in the original code, and complex and advanced queries based on relationships are possible using this method. 
+
+
+\subsection*{.QL}
+
+.QL is an object-oriented query language. It can be used to query with a similar style to SQL queries, and is used in the Semmle
+\subsection*{JQuery}
+
+\section*{JetBrains structural search}
+
+
+\section{Other JavaScript parsers}
+
+\subsection*{Speedy Web Compiler}
+
+\cite{SpeedyWebCompiler}Speedy Web Compiler is a library created for parsing JavaScript and other dialects like JSX, TypeScript faster. It is written in Rust and advertises faster speeds than Babel and is used by large organizations creating applications and tooling for the web platform. 
+
+Similar to \cite{Babel}Babel, Speedy Web Compiler is an extensible parser that allows for changing the specification of the parsed program. Its extensions are written in Rust. While it does not have as mature of a plugin system as Babel, its focus on speed makes it widely used for large scale web projects. 
+
+Speedy Web Compiler supports features out of the box such as Compilation, used for TypeScript and other languages that are compiled down to JavaScript. Bundling, which takes multiple JavaScript/TypeScript files and bundles them into a single output file, while handling naming collisions. Minification, to make the bundle size of a project smaller, transforming for use with WebAssembly, and custom plugins to change the specification of the languages parsed by SWC. 
+
+\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. 

generators/frontpage.tex

@@ -16,7 +16,7 @@
 
 \HRule \\[0.5cm]
 \begin{Huge}
-	\bfseries{Title of your master thesis}\\[0.7cm] % Title of your document
+	\bfseries{Making a template query language for EcmaScript}\\[0.7cm] % Title of your document
 \end{Huge}
 \HRule \\[0.5cm]
 
@@ -24,8 +24,8 @@
 %	AUTHOR SECTION
 %----------------------------------------------------------------------------------------
 
-\large \emph{Author:} Your name\\
-\large \emph{Supervisors:} Name of supervisors\\[2cm]
+\large \emph{Author:} Rolf Martin Glomsrud\\
+\large \emph{Supervisor:} Mikhail Barash\\[2cm]
 
 %----------------------------------------------------------------------------------------
 %   LOGO SECTION

generators/refs.bib

@@ -158,4 +158,33 @@
   pages      = {29–35},
   numpages   = {7},
   keywords   = {Greibach normal form, context free grammar, design patterns, object oriented, recursive descent parser, smalltalk}
+}
+
+@misc{SpeedyWebCompiler,
+  title   = {{Rust-based platform for the Web {\textendash} SWC}},
+  year    = {2024},
+  month   = may,
+  urldate = {2024-05-21},
+  note    = {[Online; accessed 21. May 2024]},
+  url     = {https://swc.rs}
+}
+
+@misc{Pipeline,
+  title   = {{proposal-pipeline-operator}},
+  journal = {GitHub},
+  year    = {2024},
+  month   = may,
+  urldate = {2024-05-21},
+  note    = {[Online; accessed 21. May 2024]},
+  url     = {https://github.com/tc39/proposal-pipeline-operator}
+}
+
+@misc{AcornJS,
+  title   = {{acorn}},
+  journal = {GitHub},
+  year    = {2024},
+  month   = may,
+  urldate = {2024-05-21},
+  note    = {[Online; accessed 21. May 2024]},
+  url     = {https://github.com/acornjs/acorn}
 }

report.tex

@@ -18,6 +18,8 @@
 \include{chapter/ch2}
 \include{chapter/ch3}
 \include{chapter/ch4}
+\include{chapter/related_work}
+\include{chapter/future_work}
 % Include more chapters as required.
 %%=========================================