split up more and updatE
[phd-thesis.git] / dsl / first.tex
index 68a5baf..94b5704 100644 (file)
@@ -2,11 +2,11 @@
 
 \input{subfilepreamble}
 
-\setcounter{chapter}{1}
+\setcounter{chapter}{2}
 
 \begin{document}
 \input{subfileprefix}
-\chapter{First-class data types in shallow \texorpdfstring{embedded domain-specific languages}{\glsxtrlongpl{EDSL}} using metaprogramming}%
+\chapter{First-class data types in shallow embedded domain-specific languages using metaprogramming}%
 \label{chp:first-class_datatypes}%
 \begin{chapterabstract}
        \Gls{FP} languages are excellent for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
@@ -337,7 +337,7 @@ This information can then be used to generate code according to the structure of
 Reification is done using the \haskellinline{reify :: Name -> Q Info} function.
 The \haskellinline{Info} type is an \gls{ADT} containing all the---known to the compiler---information about the matching type: constructors, instances, \etc.
 
-\section{Metaprogramming for generating \texorpdfstring{\glsxtrshort{DSL}}{DSL} functions}
+\section{Metaprogramming for generating DSL functions}
 With the power of metaprogramming, we can generate the boilerplate code for our user-defined data types automatically at compile time.
 To generate the code required for the \gls{DSL}, we define the \haskellinline{genDSL} function.
 The type belonging to the name passed as an argument to this function is made available for the \gls{DSL} by generating the \haskellinline{typeDSL} class and view instances.
@@ -785,7 +785,7 @@ If not the host language but the \gls{DSL} contains higher order functions, the
 \Citet{mcdonell_embedded_2022} extends on this idea, resulting in a very similar but different solution to ours.
 They used the technique that \citeauthor{atkey_unembedding_2009} showed and applied it to deep embedding using the concrete syntax of the host language.
 The scaffolding---e.g.\ generating the pairs, sums and injections---for embedding is automated using generics but the required pattern synonyms are generated using \gls{TH}.
-The key difference to our approach is that we specialise the implementation for each of the backends instead of providing a general implementation of data type handling operations.
+The key difference to our approach is that we specialise the implementation for each of the interpretations instead of providing a general implementation of data type handling operations.
 Furthermore, our implementation does not require a generic function to trace all constructors, resulting in problems with (mutual) recursion.
 
 \Citet{young_adding_2021} added pattern matching to a deeply \gls{EDSL} using a compiler plugin.
@@ -793,7 +793,7 @@ This plugin implements an \haskellinline{externalise :: a -> E a} function that
 Under the hood, this function translates the pattern match to constructors, deconstructors, and constructor predicates.
 The main difference with this work is that it requires a compiler plugin while our metaprogramming approach works on any compiler supporting a metaprogramming system similar to \gls{TH}.
 
-\subsection{Related work on \texorpdfstring{\glsxtrlong{TH}}{Template Haskell}}
+\subsection{Related work on Template Haskell}
 Metaprogramming in general is a very broad research topic and has been around for years already.
 We therefore do not claim an exhaustive overview of related work on all aspects of metaprogramming.
 However, we have have tried to present most research on metaprogramming in \gls{TH}.
@@ -812,7 +812,7 @@ In practise, this means that the programmer selects a skeleton and, at compile t
 \Citet{duregard_embedded_2011} wrote a parser generator using \gls{TH} and the custom quasiquoting facilities.
 From a specification of the grammar, given in verbatim using a custom quasiquoter, a parser is generated at compile time.
 \Citet{shioda_libdsl_2014} used metaprogramming in the D programming language to create a \gls{DSL} toolkit.
-They also programmatically generate parsers and a backend for either compiling or interpreting the \gls{IR}.
+They also programmatically generate parsers and an interpretation for either compiling or interpreting the \gls{IR}.
 \Citet{blanchette_liquid_2022} use \gls{TH} to simplify the development of Liquid \gls{HASKELL} proofs.
 \Citet{folmer_high-level_2022} used \gls{TH} to synthesize C$\lambda$aSH \citep{baaij_digital_2015} \glspl{AST} to be processed.
 In similar fashion, \citet{materzok_generating_2022} used \gls{TH} to translate YieldFSM programs to {C$\lambda$aSH}.
@@ -853,7 +853,7 @@ They utilise the quasiquation facilities of \gls{TH} to convert \gls{HASKELL} \g
 \Citet{egi_embedding_2022} extended \gls{HASKELL} to support non-free data type pattern matching---i.e.\ data type with no standard form, e.g.\ sets, graphs---using \gls{TH}.
 Using quasiquotation, they make a complicated embedding of non-linear pattern matching available through a simple lens.
 
-\subsubsection{\texorpdfstring{\Glsxtrlong{TTH}}{Typed Template Haskell}}\label{ssec_fcd:typed_template_haskell}
+\subsubsection{Typed Template Haskell}\label{ssec_fcd:typed_template_haskell}
 \Gls{TTH} is a very recent extension/alternative to normal \gls{TH} \citep{pickering_multi-stage_2019,xie_staging_2022}.
 Where in \gls{TH} you can manipulate arbitrary parts of the syntax tree, add top-level splices of data types, definitions and functions, in \gls{TTH} the programmer can only splice expressions but the \gls{AST} fragments representing the expressions are well-typed by construction instead of untyped.