added a section of custom DSL types used
This commit is contained in:
parent
031b5762c3
commit
8610e6456b
2 changed files with 13 additions and 4 deletions
BIN
build/report.pdf
BIN
build/report.pdf
Binary file not shown.
|
@ -351,10 +351,12 @@ In order to identify snippets of code a proposal is applicable to, we use templa
|
|||
|
||||
A template containing none of these \textit{wildcards} is matched exactly. This essentially means the match will be a direct code search for snippets where the AST of the users code match the template exactly.
|
||||
|
||||
The \textit{wildcards} are written inside a block denoted by << WILDCARD >>. Each wildcard has to have a DSL identifier, a way of referring to that wildcard in the definition of the transformation.
|
||||
The \textit{wildcards} are written inside a block denoted by << WILDCARD >>. Each wildcard has to have a DSL identifier, a way of referring to that wildcard in the definition of the transformation, and a wildcard type
|
||||
|
||||
Each wildcard has to have some form of type. These types can be node-types inherited from Babels AST definition. This means if you want a wildcard to match any \textit{CallExpression} then that wildcard should be of type CallExpression. In order to allow for multiple node-types to match against a single wildcard, \DSL allows for sum types for wildcards, allowing multiple AST node-types to be allowed to a single wildcard definition.
|
||||
|
||||
The wildcard type can also be a custom type with special functionality. Some examples of this is \texttt{anyRest}, which allows for the matcher to match it against multiple expressions/statements defined within an AST node as a list. As an example this type could match against any number of statements within a codeblock.
|
||||
|
||||
This type definition is also used to define specific behavior the program using this DSL should perform. One example of this can be found in \ref{def:pipeline}, where the DSL function \textit{anyRest} is used to allow for any amount of child nodes found together with the wildcard. This means it is feasible to match against any number of function parameters for example.
|
||||
|
||||
\begin{lstlisting}[caption={Example of a wildcard}, label={ex:wildcard}]
|
||||
|
@ -364,6 +366,11 @@ let variableName = << expr1: CallExpression | Identifier >>;
|
|||
|
||||
In \ref{ex:wildcard} a wildcard section is defined on the right hand side of an assignment statement. This wildcard will match against any AST node classified as a CallExpression or an Identifier.
|
||||
|
||||
\subsection{\DSL custom matching types}
|
||||
|
||||
\texttt{anyNExprs} is a custom DSL matching type. This type allows the matcher to match a specific section of the JavaScript template against any number of elements stored within a list on the AST node Object it is currently trying to match. Using this allows for transferring any number of expression from the match into the transformed code. This custom type is used in \ref{def:pipeline}.
|
||||
|
||||
\texttt{anyNStatements} is a custom DSL matching type. This type allows the matcher to match against any number of Statements within a section of JavaScript. This custom type is used in \ref{def:doExpression}
|
||||
|
||||
\subsection{Transforming}
|
||||
|
||||
|
@ -487,7 +494,7 @@ This first pair definition \texttt{SingleArgument} of the Pipeline proposal will
|
|||
|
||||
The \cite[Do Proposal]{Proposal:DoProposal} can also be defined with this tool. This definition will never catch all the applicable sections of the users code, and is very limited in where it might discover this proposal is applicable. This is due to the Do Proposal introducing an entirely new way to write JavaScript (Expression-oriented programming). If the user running this tool has not used the current status-quo way of doing expression-oriented programming in JavaScript, \DSL will probably not find any applicable snippets in the users code. However, in a reasonably large codebase, some examples will probably be discovered.
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL}, label={def:DoProposal}]
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL}, label={def:doExpression}]
|
||||
proposal DoExpression{
|
||||
pair arrowFunction{
|
||||
applicable to {
|
||||
|
@ -507,7 +514,7 @@ proposal DoExpression{
|
|||
pair immediatelyInvokedUnnamedFunction {
|
||||
applicable to {
|
||||
function(){
|
||||
<<blockStatements: anyStatementList>>
|
||||
<<blockStatements: anyNStatements>>
|
||||
return << returnExpr: Expr >>
|
||||
}();
|
||||
}
|
||||
|
@ -522,3 +529,5 @@ proposal DoExpression{
|
|||
}
|
||||
|
||||
\end{lstlisting}
|
||||
|
||||
\chapter*{title}
|
Loading…
Reference in a new issue