cleanup and start of intro

chapter/ch2.tex

@@ -102,4 +102,3 @@ A language workbench is a tool created to facilitate the development of a comput
 Language workbenches support generating tooling for languages, as most modern computer languages are backed by some form of tooling. This tooling comes in the form of language parsing, language servers for integrated development environments, along with other tooling for using the language created within the language workbench. 
 
 A language is defined in a language workbench using a grammar definition. This grammar is a formal specification of the language that describes how each language construct is composed and the structure of the language. This allows the language workbench to determine what is a valid sentence of the language. This grammar is used to create the the AST of the language, which is the basis for all the tools generated by the language workbench. Many such language workbenches exist, such as Langium~\cite{Langium}, Xtext~\cite{Xtext}, Jetbrains MPS, and Racket. 
-

chapter/ch3.tex

@@ -5,7 +5,7 @@ syntactic proposals for ECMAScript.
 
 \section{The core idea}
 
-When a use of ECMAScript wants to suggest a change to the language, the idea of the change has to be described in a Proposal. A proposal is a general way of describing a change and its requirements, this is done by a language specification, motivation for the idea, and general discussion around the proposed change. A proposal ideally also needs backing from the community of users that use ECMAScript, this means the proposal has to be presented to users some way. This is currently done by many channels, such as polyfills, code examples, and as beta features of the main JavaScript engines, however, this paper wishes to showcase proposals to users by using a different avenue.  
+When a user of ECMAScript wants to suggest a change to the language, the idea of the change has to be described in a Proposal. A proposal is a general way of describing a change and its requirements, this is done by a language specification, motivation for the idea, and general discussion around the proposed change. A proposal ideally also needs backing from the community of users that use ECMAScript, this means the proposal has to be presented to users some way. This is currently done by many channels, such as polyfills, code examples, and as beta features of the main JavaScript engines, however, this paper wishes to showcase proposals to users by using a different avenue.  
 
 Users of ECMAScript have a familiarity with code they themselves have written. This means they have knowledge of how their own code works and why they might have written it a certain way. This project aims to utilize this pre-existing knowledge to showcase new proposals for ECMAScript. This way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal authors.
 

chapter/future_work.tex

@@ -1,12 +1,21 @@
-\chapter{Future Work}
+\chapter{Conclusions \& 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. 
+\section{Conclusions}
 
-\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 development 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. 
+In this thesis, we have developed a way to define transformations of JavaScript based on a proposal definition. This tool is created to facilitate tooling that enables early feedback on syntactic proposals for ECMAScript. 
 
-\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. 
+\section{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 development 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 Babel~\cite{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. 
+
+\textbf{}

chapter/introduction.tex

@@ -1,6 +1,16 @@
 \chapter{Introduction}
 
-Intro goes here
+The development of the programming language ECMAScript, which is defined by the ECMA-262 language standard, is worked on by Technical Committee 39. The committee has the responsibility to explore proposals suggested for addition to ECMASript. During this process, proposals go through many iterations in the exploration process of solutions to the problem identified in the proposal. During this process, the community of JavaScript developers can give feedback on proposed solutions. This feedback has to be of some quality, and it is therefore adamant that the user's giving feedback understand the proposal well. This thesis suggests a way of presenting proposals to users by exploiting their familiarity with their own code. This idea applies to syntactic proposals, which are proposals that contains either no, or very limited change to functionality, and no change to semantics. 
+
+This thesis discusses a way of defining transformations of code specifically for syntactic proposals. These transformations are used to showcase a syntactic proposal to users by transforming code the user's are already familiar with. The theory is this will help user's understand proposals faster and easier, as they are already familiar with the code the proposal is being presented in. The two proposals discussed in this thesis to evaluate the tool are "Do Expression"~\cite{Proposal:DoProposal} and "Pipeline"~\cite{Pipeline}.
+
+The language defined in this thesis is titles \DSL, and allows for structured template queries to be written, these templates are used to search for code that is applicable to a proposal. A code snippet being applicable to a proposal, means it could have been written using that proposal. These queries come with a definition of a transformation, which will use the matched code snippet in the user's code, and transform it to use the features of the proposal. This newly transformed code can then be presented to the user along with the original unchanged code. This allows a user to see an example of the proposal being applied, and they can then give feedback on the proposal based on that. 
+
+
+
+
+
+
 
 
 

chapter/related_work.tex

@@ -20,11 +20,11 @@ To allow for simple analysis and refactoring of code, there exists many query la
 
 CodeQL~\cite{CodeQL} is an object-oriented query language, it was previously known as .QL. . CodeQL is used to analyze code semantically to discover vulnerabilities~\cite{CodeQLStuff}. CodeQL has taking inspiration from several areas of computer science to create their query language~\cite{CodeQLStuff}, such a inspiration from SQL, Datalog, Eindhoven QUantifier Notation, and Classes are Predicates. 
 
-An example of how queries are written in CodeQL can be defined below. This query will find all methods that declare a method \texttt{getNumber} and a method \texttt{setNumber}. 
+An example of how queries are written in CodeQL can be defined below~\cite{CodeQL}. This query will find all methods that declare a method \texttt{equals} and not a method \texttt{hashCode}. This query is performed using an erroneous class \texttt{c}, and we define what properties that class should have.  
 \begin{lstlisting}
 from Class c
-where c.declaresMethod("getNumber") and
+where c.declaresMethod("equals") and
-    (c.declaresMethod("setNumber")) and
+    not(c.declaresMethod("hashCode")) and
     c.fromSource()
 select c.getPackage(), c
 \end{lstlisting}
@@ -33,27 +33,34 @@ The syntax of writing queries in CodeQL is not similar to \DSL, as it is SQL-lik
 
 \subsection{PMD XPath}
 
-PMD XPath is a language for Java source code querying, it supports querying of all Java constructs. The reason it has this wide support is due to it constructing the entire codebase's AST in XML format, and then performing the query on the XML. This makes the query language very versatile for static code analysis, and is used in the PMD static code analysis tool.  
+PMD XPath is a language for Java source code querying, it supports querying of all Java constructs~\cite{ProgrammingLanguageEcolutionViaSourceCodeQueryLanguages}. The reason it has this wide support is due to it constructing the entire codebase's AST in XML format, and then performing the query on the XML. These queries are performed using XPath rules, that define the matching on the XML. This makes the query language very versatile for static code analysis, and is used in the PMD static code analysis tool.  
 
 \begin{lstlisting}
-public class a{
+public class KeepingItSerious{
-    int someVar;
+    Delegator bill; // FieldDeclaration
-    private void run(){
+
-        int otherVar;
+    public void method(){
+        short bill; // LocalVariableDeclaration
     }
 }
 \end{lstlisting}
 
-There are two queries with PMD XPath defined in the example below. If we execute these on the code above, the first will return both \texttt{someVar} and \texttt{otherVar}, while the second will only return \texttt{otherVar}. The reason the second limits the search, is we define that the parent of the variable declaration has to be a method. This is done by moving three levels up in the XML and checking the name of the node residing there. 
+There are two queries with PMD XPath defined in the example below~\cite{PMDXPath}. If we execute these on the code above, the first will match against the field declaration \texttt{Delegator bill} and \texttt{short bill}, while the second will only return \texttt{short bill}. The reason the second limits the search, is we define the type of the declaration.  
 \begin{lstlisting}
-//LocalVariableDeclaration
+//VariableId[@Name = "bill"]
-//LocalVariableDeclaration[name(../../..) = "methodDeclaration"]
+//VariableId[@Name = "bill" and ../../Type[@TypeImage = "short"]]
 \end{lstlisting}
 
-Comparing this tool to \DSL, we can see it is good at querying code based on structure, which our tool also supports. The main difference is the manor of which each tool does this, \DSL uses JavaScript templates to perform the query, making writing queries simple for users as they are based in JavaScript. PMD XPath uses a custom query language to perform structural queries that is quite verbose, and requires extended knowledge of the AST that is currently being queried.  
+Comparing this tool to \DSL, we can see it is good at querying code based on structure, which our tool also excels at. The main difference is the manor of which each tool does this, \DSL uses JavaScript templates to perform the query, making writing queries simple for users as they are based in JavaScript. PMD XPath uses XPath to perform define structural queries that is quite verbose, and requires extended knowledge of the AST that is currently being queried.  
 
 \subsection{XSL Transformations}
 
+XSLT~\cite{XSLT} is a language created to perform transformations of XML documents, transforming an XML document into a different format, this can be into other XML documents, HTML or even plain text. 
+
+XSLT is part of Extensible Stylesheets Language family of programs. The XSL language is expressed in the form of a stylesheet~\cite[1.1]{XSLT}, whose syntax is defined in XML. This language uses a template based approach to define matches on specific patterns in the source to find sections to transform. These transformations are defined by a transformation declaration that describes how the output of the match should look. 
+
+This language defines matching and transformation very similarly to \DSL, and uses the same technique, where the transformation declaration describes how the output should look, and not exactly how the transformation is performed. 
+
 \subsection{Jackpot}
 
 Jackpot~\cite{Jackpot} is a query language created for the Apache Netbeans platform~\cite{ApacheNetBeans}, it has since been mostly renamed to Java Declarative Hints Language, we will continue to refer to it as Jackpot in this section. The language uses declarative patterns to define source code queries, these queries are used in conjunction with multiple rewrite definitions. This is used in the Apache Netbeans suite of tools to allow for declarative refactoring of code. 
@@ -89,13 +96,15 @@ Speedy Web Compiler~\cite{SpeedyWebCompiler} is a library created for parsing Ja
 
 Similar to Babel~\cite{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. 
+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. 
 
-Compared to Babel used in this paper, SWC focuses on speed, as its main selling point is a faster way of developing web projects. 
+Compared to Babel used in this paper, SWC focuses on speed, as its main selling point is a faster way of developing web projects. This parser was considered to be used for this project, however it had some shortcomings which made us decide it was not a good fit. SWC is written in Rust, which considering this project is targeted at TC39 we wanted it to be in JavaScript or one of JavaScript's dialects. SWC does have such an extensive library of early stage proposal plugins as Babel, this by itself is the deal breaker for use in this project, as we rely un support of proposals as early as stage one. 
 
 \subsection*{Acorn}
 
-Acorn~\cite{AcornJS} is parser written in JavaScript to parse 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.  and has it's own tree traversal library Acorn Walk. 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~\cite{AcornJS} is parser written in JavaScript to parse JavaScript and it's related languages. Acorn focuses on plugin support in order to support extending and redefinition of how it's internal parser works. Acorn focuses on being a small and fast JavaScript parser, has it's own tree traversal library Acorn Walk. Babel is originally a fork of Acorn, while Babel has since had a full rewrite, Babel is still heavily based on Acorn and Acorn-jsx~\cite{BabelAcornBased}. 
+
+Acorn suffers from a similar problem to SWC when it was considered for use in this project. It does not have the same wide community as Babel, and does not have the same recommendation from TC39 as Babel does~\cite{TC39RecommendBabel}. Even though it supports plugins and the plugin system is powerful, there does not exist the same amount of pre-made plugins for early stage proposals as Babel has. 
 
 
 

generators/refs.bib

@@ -228,6 +228,14 @@
   url     = {https://netbeans.apache.org/front/main/index.html}
 }
 
+@misc{PMDXPath,
+  title   = {{Writing XPath rules {$\vert$} PMD Source Code Analyzer}},
+  year    = {2024},
+  month   = apr,
+  urldate = {2024-05-30},
+  note    = {[Online; accessed 30. May 2024]},
+  url     = {https://docs.pmd-code.org/latest/pmd_userdocs_extending_writing_xpath_rules.html}
+}
 @misc{StructuralSearchAndReplaceJetbrains,
   title   = {{Structural search and replace {$\vert$} IntelliJ IDEA}},
   journal = {IntelliJ IDEA Help},
@@ -479,3 +487,36 @@
   keywords  = {},
   doi       = {10.1109/SCAM.2007.31}
 }
+@misc{BabelAcornBased,
+  title   = {{@babel/parser {$\cdot$} Babel}},
+  year    = {2024},
+  month   = may,
+  urldate = {2024-05-30},
+  note    = {[Online; accessed 30. May 2024]},
+  url     = {https://babeljs.io/docs/babel-parser#credits}
+}
+
+
+@inbook{ModelToModelTransformations,
+  author    = {W{\k{a}}sowski, Andrzej
+               and Berger, Thorsten},
+  title     = {Model and Program Transformation},
+  booktitle = {Domain-Specific Languages: Effective Modeling, Automation, and Reuse},
+  year      = {2023},
+  publisher = {Springer International Publishing},
+  address   = {Cham},
+  pages     = {233--292},
+  abstract  = {So far, we focused on defining the syntax of DSLs in efficient ways. We worked with abstract and concrete syntax. We have seen tools that can transform syntax definitions (meta-models and grammars in our case) not only into model editors, but into a whole infrastructure for processing models that adhere to the syntax definition.},
+  isbn      = {978-3-031-23669-3},
+  doi       = {10.1007/978-3-031-23669-3_7},
+  url       = {https://doi.org/10.1007/978-3-031-23669-3_7}
+}
+
+@misc{XSLT,
+  title   = {{XSL Transformations (XSLT) Version 2.0 (Second Edition)}},
+  year    = {2021},
+  month   = mar,
+  urldate = {2024-05-30},
+  note    = {[Online; accessed 30. May 2024]},
+  url     = {https://www.w3.org/TR/xslt20}
+}