polsevev/master
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

More on background

Browse source
This commit is contained in:
Rolf Martin Glomsrud 2024-05-30 18:47:33 +02:00
parent 26d24ad0e1
commit 635fe8cee6
8 changed files with 93 additions and 63 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.vscode/notes/Background fix vendored Normal file
View file

@ -0,0 +1,4 @@
More complex example of AST babel
Introduce why we use Babel, its plugins and State 2 proposals
XSLT

BIN
build/report.pdf
View file

Binary file not shown.

58
chapter/ch2.tex
View file

@ -33,33 +33,41 @@ Stage 4, the proposal is completed and included in the standard.
\subsection*{Abstract Syntax Tree}
Abstract Syntax Trees (AST) is one of the most common representations used to represent source code of programming languages~\cite{AST3}. It allows for the storage of structured text into a tree, this is used in applications that work with source code, as source code is a form of structured text.
An abstract syntax tree is a tree representation of source code. Every node of the tree represents a construct from the source code. ASTs remove syntactic details that are present in the source code, and while maintaining the structure of the program with its tree. Each node is set to represent elements of the programming language, some common ones are statements, expressions, declarations and other language concepts. Every node type represents a grammatical construct in the language the AST was built from.
ASTs are important for working with source code, they are used by almost any tool that has to represent source code in some way to perform operations with it~\cite{AST3}. This is because the structure is simpler to work with then raw text, especially when considering tools like compilers, interpreters, or code transformation tools.
ASTs are built by language parsers. A language parser takes the raw source code of a language, and parses the code into an AST while maintaining its structure but discarding irrelevant information. A simple example of how JavaScript is parsed into an AST can be seen in Figure~\ref{ex:srcToAST}.
\subsection*{Babel}
Babel is a JavaScript toolchain, its main usage is converting ECMASCript 2015 and newer into backwards older versions of JavaScript. The conversion to older versions is done to increase compatibility of JavaScript in older environments such as older browsers.
Babel is a JavaScript toolchain, its main usage is converting ECMASCript 2015 and newer into older versions of JavaScript. The conversion to older versions is done to increase compatibility of JavaScript in older environments such as older browsers.
Babel has a suite of libraries used to work with JavaScript source code, each library relies on Babels AST definition~\cite{BabelAST}. The AST specification Babel uses tries to stay as true to the ECMAScript standard as possible~\cite{BabelSpecCompliant}, which has made it a recommended parser to use for proposal transpiler implementations~\cite{TC39RecommendBabel}. A simple example of how source code parsed into an AST with Babel looks like can be seen in Figure~\ref{ex:srcToAST}.
\begin{figure}[H]
\noindent\begin{minipage}{.45\textwidth}
\noindent\begin{minipage}{.30\textwidth}
\begin{lstlisting}[language={JavaScript}]
let name = 100;
let name = f(100);
\end{lstlisting}
\end{minipage}\hfil
\noindent\begin{minipage}{.45\textwidth}
\noindent\begin{minipage}{.65\textwidth}
\begin{center}
\begin{tikzpicture}[
squarednode/.style={rectangle, draw=red!60, fill=red!5, very thick, minimum size=2mm}, node distance=10mm and 5mm
squarednode/.style={rectangle, draw=red!60, fill=black!5, very thick, minimum size=2mm}, node distance=10mm and 5mm
]
\node[squarednode] (VarDecl) {VariableDeclaration};
\node[squarednode] (VarDeclarator) [below=of VarDecl] {VariableDeclarator};
\node[squarednode] (id) [below left= 10mm and -10mm of VarDeclarator] {Identifier};
\node[squarednode] (init) [below right= 10mm and -10mm of VarDeclarator] {NumericLiteral};
\node[squarednode] (id) [below left= 10mm and -10mm of VarDeclarator] {Identifier: name};
\node[squarednode] (callExpr) [below right= 10mm and -10mm of VarDeclarator] {CallExpression};
\node[squarednode] (cid) [below left= 10mm and -10mm of callExpr] {Identifier: f};
\node[squarednode] (arg) [below right= 10mm and -15mm of callExpr] {NumericLiteral: 100};
\draw[->] (VarDecl.south) -- (VarDeclarator.north);
\draw[->] (VarDeclarator.south) -- (id.north);
\draw[->] (VarDeclarator.south) -- (init.north);
\draw[] (VarDecl.south) -- (VarDeclarator.north);
\draw[] (VarDeclarator.south) -- (id.north);
\draw[] (VarDeclarator.south) -- (callExpr.north);
\draw[] (callExpr.south) -- (cid.north);
\draw[] (callExpr.south) -- (arg.north);
\end{tikzpicture}
\end{center}
\end{minipage}\hfil
@ -67,27 +75,33 @@ let name = 100;
\end{figure}
Babel's mission is to transpile newer version of JavaScript into older versions that are more compatible with different environments. It has a rich plugin system to allow a myriad of features to be enabled or disabled. This makes the parser very versatile to fit different ways of working with JavaScript source code. This plugin system is built to enable or disable several language constructs,
One of Babel's more prominent features is \texttt{@babel/parse}~\cite{BabelParser} with plugins. This library allows parsing of JavaScript experimental features. These features are usually proposals that are under development by TC39, and the development of these plugins are a part of the proposal deliberation process. This allows for experimentation as early as stage one of the proposal development process. Some examples of proposals that were first supported by Babels plugin system are "Do Expression"~\cite{Proposal:DoProposal} and "Pipeline"~\cite{Pipeline}. These proposals are both currently in the very early stage of development, with "Do Expression" being stage one, and "Pipeline" being stage 2.
Babel's mission is to transpile newer version of JavaScript into older versions that are more compatible with different environments. It has a rich plugin system to allow a myriad of features to be enabled or disabled. This makes the parser very versatile to fit different ways of working with JavaScript source code.
\section{Source Code Querying}
Babels main feature is \texttt{@babel/parse}~\cite{BabelParser} and its plugins. This library allows parsing of JavaScript experimental features. These features are usually proposals that are under development by TC39, and the development of these plugins are a part of the proposal deliberation process. Some examples of proposals that were first supported by Babels plugin system are "Do Expression"~\cite{Proposal:DoProposal} and "Pipeline"~\cite{Pipeline}.
Source code querying is the action of searching source code to extract some information or find specific sections of code. This is primarily done using several varying techniques, and is a core part of many tools developers use. The primary use cases for source code querying is code understanding, analysis, code navigation, enforcement of styles along with others. All these are important tools developers use when writing programs, and they all rely on some form of source code queries.
Source code querying comes in many forms, the simplest of which is text search. Since source code is primarily text, one can apply text search techniques to perform a query, this can be regular string search like with CTRL+F in the browser, or a more complex approach using regular expressions with tools like grep. Both these methods cannot allow for queries based on the structure of the code, and rely solely on its syntax. AST based queries allow queries to be written based on both syntax and structure, and are generally more powerful than regular text based queries. Another technique for code querying is creating queries based on semantics of code. Recently, querying based on the semantics of code is more feasible by using large language models to perform the queries.
\section{Source code Querying}
Source code querying is a technique used to extract information from source code. Since source code is just structured text, one can treat it as a database, allowing for queries to be written and perform operations on that data.
Source code Querying enables developers to search through their code for specific patterns based on a query written. These queries can come in many different forms. Such as SQL-like queries, structured queries,
This kind of querying is very useful for programs such as Integrated Development Environments, source code transformations, and other tasks which require searching through code. An example of source code querying being used in an IDE is Jetbrains structural search and replace~\cite{StructuralSearchAndReplaceJetbrains}.
Source code querying is used in many areas of software development. Some of the more prevalent areas is in Integrated Development Environments (IDEs), as these tools are created to write source code, and therefore rely on querying of the source code written for many of their features. Some of these features include code navigation, static code analysis, or complex code searching. One such example of code querying being used in an IDE is Jetbrains structural search and replace~\cite{StructuralSearchAndReplaceJetbrains}, where we define queries based on code structure to find and replace sections of our program.
\section{Domain Specific languages}
Domain specific languages are computer languages specialized to a specific domain. If we compare a DSL to a general purpose language like Python, C++ or JavaScript, these GPL are not designed with a specific task in mind, but have a more general feature set to allow them to be used in a wide array of applications. What a domain is for a DSL is not so simple to define, as there is no general way to define exactly the point in which a DSL becomes a GPL and vice versa. This difference is defined more like a spectrum, in which DSL is on one end and GPL is on the other~\cite{DSLSANDHOW}.
\subsection*{Language Workbenches}
DSL's has some clear advantages when being applied to a specific domain compared to GPL's. A DSL allows for very concise and expressive code to be written that is specifically designed for the application, in which a GPL might require specific implementations to suit the domain. Using a DSL might result in faster development because of this expressiveness within the domain, this specificity to a domain might also increase correctness. However, there are also clear disadvantages to DSL's, the restrictiveness of a DSL might become a hinderance if it is not well designed to the domain. DSL's also might have a learning curve, making the knowledge required to use them a hinderance. Developing the DSL might also be a hinderance, as a DSL requires both knowledge of the domain and knowledge of language design.
One part of creating a software language is the tooling for that language. Most modern software languages are backed by some form of tooling, one important tool for a language is the language server. This is created to allow for features such as syntax highlighting, auto completion, error checking et.al. When creating a software language, generating tooling to support this features can be done using a \emph{language workbench}~\cite{LanguageWorkbench}. The language in question is specified within the language workbench, using a grammar. That grammar is then used to generate the tooling of the language. Many such language workbenches exist, such as Langium~\cite{Langium}, Xtext~\cite{Xtext}, Jetbrains MPS, and Racket.
\section{Language Workbenches}
A language workbench is a tool created to facilitate the development of a computer language, such as a DSL. Language workbenches also create tooling for languages defined within them, and help with the language development process in general.
One part of creating a computer language is the tooling for that language. Most modern software languages are backed by some form of tooling, one important tool for a language is the language server. This is created to allow for features such as syntax highlighting, auto completion, error checking et.al. When creating a software language, generating tooling to support this features can be done using a \emph{language workbench}~\cite{LanguageWorkbench}. The language in question is specified within the language workbench, using a grammar. That grammar is then used to generate the tooling of the language. Many such language workbenches exist, such as Langium~\cite{Langium}, Xtext~\cite{Xtext}, Jetbrains MPS, and Racket.

11
chapter/ch5.tex
View file

@ -26,7 +26,7 @@ Await to promise also has an expected number of matches, but this evaluation pro
\hline
"Do" expression & 480 & 111 & 3340 \\
\hline
Await to Promise & 7000 & 574 & 3340 \\
Await to Promise & 143 & 75 & 3340 \\
\hline
\end{tabular}
\end{center}
@ -48,7 +48,7 @@ Await to promise also has an expected number of matches, but this evaluation pro
\hline
"Do" expression & 277 & 55 & 1384 \\
\hline
Await to Promise & 186 & 114 & 1384 \\
Await to Promise & 13 & 7 & 1384 \\
\hline
\end{tabular}
\end{center}
@ -65,11 +65,11 @@ Await to promise also has an expected number of matches, but this evaluation pro
\hline
Proposal & Matches found & Files with matches & Files searched\\
\hline \hline
"Pipeline" & 16353 & 1266 & 3572 \\
"Pipeline" & 16353 & 1266 & 2051 \\
\hline
"Do" expression & 79 & 60 & 2051 \\
\hline
Await to Promise & 107 & 89 & 3572 \\
Await to Promise & 30 & 13 & 2051 \\
\hline
\end{tabular}
\end{center}
@ -110,7 +110,7 @@ Await to promise also has an expected number of matches, but this evaluation pro
\hline
"Do" expression & 46 & 26 & 401 \\
\hline
Await to Promise & 8 & 6 & 401 \\
Await to Promise & 12 & 7 & 401 \\
\hline
\end{tabular}
\end{center}
@ -262,3 +262,4 @@ async function getCurrentRules() {
\caption*{"Await to Promise" transformation, taken from \texttt{next.js/test/integration/typescript-hmr/index.test.js}}
\end{figure}
As can be seen in the results, ......... Some proposals more impactful than others

68
chapter/related_work.tex
View file

@ -2,72 +2,92 @@
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.
AoP, is a programming paradigm that gives increased modularity by allowing for a high degree of separation of concerns, specifically focusing on cross-cutting concerns.
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
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, or error handling, but could be any concern that are shared across an application.
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.
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 advices,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.
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 performing a rewrite of the code during execution to add functionality to multiple places in the executing code.
\section*{Other source code query languages}
\section{Other source 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 some of these languages for querying source code, and how they relate to \DSL developed in this thesis.
To allow for simple analysis and refactoring of code, there exists many query languages designed to query source 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 some of these languages for querying source code, and how they relate to \DSL developed in this thesis.
\subsection*{Browse-By-Query}
\subsection{CodeQL}
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.
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}.
\begin{lstlisting}
from Class c
where c.declaresMethod("getNumber") and
(c.declaresMethod("setNumber")) and
c.fromSource()
select c.getPackage(), c
\end{lstlisting}
\subsection*{CodeQL}
The syntax of writing queries in CodeQL is not similar to \DSL, as it is SQL-like, and not declarative patterns, which makes the writing experience of the two languages very different. Writing CodeQL queries are similar to querying a database, while queries written in \DSL are similar to defining an example of the structure you wish to search for.
CodeQL is an object-oriented query language, it was previously known as .QL. It supports querying a wide array of data structures, code being one of them. \cite{ProgrammingLanguageEcolutionViaSourceCodeQueryLanguages}. CodeQL is used to analyze code semantically to discover vulnerabilities~\cite{CodeQL}.
\subsection{PMD XPath}
\subsection*{PMD XPath}
PMD is the most versatile query language for Java source code querying out of all the ones explored in this section~\cite{ProgrammingLanguageEcolutionViaSourceCodeQueryLanguages}. PMD supports querying of all Java constructs, it has this wide support due to constructing the entire codebase's AST in XML format. This language was built for static code analysis, and therefore is used in the PMD source code analyzer.
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.
\begin{lstlisting}
public class a{
int someVar;
private void run(){
int otherVar;
}
}
\end{lstlisting}
If we wish to query the Java source code in the listing above to find the ids of all variable declarations, the query will look as follows:
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.
\begin{lstlisting}
//VariableDeclaratorId
//LocalVariableDeclaration
//LocalVariableDeclaration[name(../../..) = "methodDeclaration"]
\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.
\subsection*{Jackpot}
\subsection{XSL Transformations}
\cite{Jackpot}Jackpot is a query language created for the \cite{ApacheNetBeans}Apache Netbeans platform, 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.
\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.
This is quite similar to the form of \DSL, as both language define som query by using similar structure, in Jackpot you define a \textit{pattern}, then every match of that pattern can be re-written to a \textit{fix-pattern}, each fix-pattern can have a condition attached to it. This is quite similar to the \textit{applicable to} and \textit{transform to} sections of \DSL. Jackpot also supports something similar to the wildcards in \DSL, as you can define variables in the \textit{pattern} definition and transfer them over to the \textit{fix-pattern} definition. This is closely related to the definition of wildcards in \DSL, though without type restrictions and notation for matching more than one AST node.
The example of a query and transformation below, will query the code for variable declarations with initial value of 1, and then change them into a declaration with initial value of 0.
\begin{lstlisting}
"change declarations of 1 to declarations of 0":
int $1 = 1;
=> int $1 = 0
\end{lstlisting}
\section*{JetBrains structural search}
\section{JetBrains structural search}
JetBrains integrated development environments have a feature that allows for \cite{StructuralSearchAndReplaceJetbrains} structural search and replace. This feature is intended for large code bases where a developer wants to perform a search and replace based on syntax and semantics, not just a regular text based search and replace. A search is applied to specific files of the codebase or the entire codebase. It does not recursively check the entire static structure of the code, but this can be specified in the user interface of structural search and replace.
JetBrains integrated development environments have a feature that allows for structural search and replace~\cite{StructuralSearchAndReplaceJetbrains}. This feature is intended for large code bases where a developer wants to perform a search and replace based on syntax and semantics, not just a regular text based search and replace. A search is applied to specific files of the codebase or the entire codebase. It does not recursively check the entire static structure of the code, but this can be specified in the user interface of structural search and replace.
When doing structural search in Jetbrains IntelliJ IDEA, templates are used to describe the query used in the search. These templates use variables described with \texttt{\$variable\$}, these allow for transferring context to the structural replace.
This tool is an interactive exprience, where each match is showcased in the find tool, and the developer can decide which matches to apply the replace template to. This allows for error avoidance and a stricter search that is verified by humans. If the developer wants, they do not have to verify each match and just replace everything.
This tool is an interactive experience, where each match is showcased in the find tool, and the developer can decide which matches to apply the replace template to. This allows for error avoidance and a stricter search that is verified by humans. If the developer wants, they do not have to verify each match and just replace everything.
When comparing this tool to \DSL and its corresponding program, there are some similarities. They are both template based, which means a search uses a template to define query, both templates contain variables/wildcards in order to match against a free section, and the replacing structure is also a template based upon those same variables. A way of matching the variables/wildcards of structural search and replace also exists, one can define the amount of X node to match against, similar to the \texttt{+} operator used in \DSL. A core difference between \DSL and structural search and replace is the variable type system. When performing a match and transformation in \DSL the types are used extensively to limit the match against the wildcards, while this limitation is not possible in structural search and replace.
\section{Other JavaScript parsers}
This section will explore other JavaScript parsers that could have been used in this project. We will give a brief introduction of each of them, and discuss why they were not chosen.
\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.
Speedy Web Compiler~\cite{SpeedyWebCompiler} 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.
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.
@ -75,7 +95,7 @@ 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~\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.

2
generators/appendix-a.tex
View file

@ -1,4 +1,4 @@
\chapter{Generated code from Protocol buffers}
\chapter{TypeScript types of wildcard type expressions}
\begin{lstlisting}[language={JavaScript},caption={TypesScript types of Type Expression AST},label={ex:typeExpressionTypes}]
export interface Identifier extends WildcardNode {

2
generators/imports.sty
View file

@ -30,7 +30,7 @@
\usepackage{amsmath}
\usepackage{titlesec}
\usepackage{setspace}
\singlespacing
\onehalfspacing
\usepackage{fullpage}
\graphicspath{{figures/}}
\usepackage{algpseudocode}

9
generators/refs.bib
View file

@ -397,15 +397,6 @@
}
@misc{Efftinge2024Feb,
author = {Efftinge, Sven and Spoenemann, Miro},
title = {{Xtext - Language Engineering Made Easy!}},
year = {2024},
month = feb,
urldate = {2024-05-29},
note = {[Online; accessed 29. May 2024]},
url = {https://eclipse.dev/Xtext}
}
@article{ExpressionOriented,
author = {Bantchev, Boyko B.},
title = {{Putting more meaning in expressions}},