Finished DSLSH

chapter/ch2.tex

@@ -84,10 +84,9 @@ Domain specific languages are software languages specialized to a specific narro
 
 \section{Language Workbenches}
 
-\textbf{REWRITE IN A MORE GENERAL SENSE, I AM SO LOST!}
+A language workbench is a tool created to facilitate the development of a computer language, such as a DSL. 
 
-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. 
 
-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. 
+Language workbenches support generating tooling for languages, as most modern computer languages are backed by some form of tooling. One such tool is a language parser that is generated from the language definition within the language workbench. Another such tool commonly generated by a language workbench is a language server for integrated development environments, these language servers provide functionality such as syntax highlighting, code navigation, error highlighting, along with others. 
 
 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

@@ -646,34 +646,23 @@ The specification of ``Await to promise'' in \DSL{} is created to match asynchro
 
 The transformation definition has to use an async arrow function as argument for \texttt{then}, as there might be more await expressions contained within \texttt{statements}.
 
-\section{\DSL{}SH}
+\section{\DSL{}-SH}
 
-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. 
+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, we call this \DSL{}-SH. The reason for this is we wanted an alternative to \DSL{}, as if this tool is to be used by TC39, we want to present several possible ways to specify a proposal. This has an added benefit of allowing our tool to be independent from the dependencies of \DSL{}-SH.  
 
-\DSL{}SH 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 \DSL{}SH you define a \texttt{prelude}, which is 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. 
+\DSL{}-SH is less of an actual language, and more of a program API, it allows for defining proposals purely in JavaScript Object, which is meant to allow a more modular way of using this idea. In \DSL{}-SH you define a \emph{prelude}, which is a series of variable declarations in JavaScript. These variable declarations are used to define the type expressions of wildcards, where the identifier of the variable declaration is the identifier of the wildcard, and the expression of the declaration is a string containing the wildcard type expression. 
+The templates are defined in a similar manner to \DSL{}, however one does not write wildcard blocks, and instead use the identifier of the wildcard directly. This makes it very clear where wildcards are allowed and might produce a more natural way of defining templates. 
+
+In the example below is the first \texttt{case} of the ``Pipeline'' proposal defined using \DSL{}-SH JavaScript object. We define the wildcards in the object key \texttt{prelude}, where it is defined as valid JavaScript. The variable declarations define the wildcards, and we use the variables defined to reference wildcards in the templates. 
 
-\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;"
+    prelude: `
+        let someFunctionIdent = "Identifier || MemberExpression";
+        let someFunctionParam = "Expression";
+        `,
+    applicableTo: "someFunctionIdent(someFunctionParam);",
+    transformTo: "someFunctionParam |> someFunctionIdent(%);"
 }
 \end{lstlisting}
-\end{minipage}\hfil