\chapter[First-class data types in shallow \acrshortpl{EDSL} using metaprogramming]{First-class data types in shallow \acrlongpl{EDSL} using metaprogramming}%
\label{chp:first-class_datatypes}%
\begin{chapterabstract}
- Functional programming languages are excellent candidates for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
+ \Gls{FP} languages are excellent candidates for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
However, data types defined in the host language are not automatically available in the embedded language.
To do so, all the operations on the data type must be ported to the \gls{EDSL} resulting in a lot of boilerplate.
\end{chapterabstract}
\section{Introduction}
-Functional programming languages are excellent candidates for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
+\Gls{FP} languages are excellent candidates for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
By expressing the language constructs in the host language, the parser, the type checker, and the run time can be inherited from the host language.
Unfortunately, data types defined in the host language are not automatically available in the \gls{EDSL}.
-The two main strategies for embedding \glspl{DSL} in a functional language are deep embedding (also called initial) and shallow embedding (also called final).
+The two main strategies for embedding \glspl{DSL} in a \gls{FP} language are deep embedding (also called initial) and shallow embedding (also called final).
Deep embedding represents the constructs in the language as data types and the semantics as functions over these data types.
This makes extending the language with new semantics effortless: just add another function.
In contrast, adding language constructs requires changing the data type and updating all existing semantics to support this new construct.
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 \gls{DSL} functions}
+\section{Metaprogramming for generating \texorpdfstring{\acrshort{DSL}}{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.
Willis et al.\ used \gls{TTH} to remove the overhead of parsing combinators~\citep{willis_staged_2020}.
\section{Discussion}
-Functional programming languages are especially suitable for embedding \glspl{DSL} but adding user-defined data types is still an issue.
+\Gls{FP} languages are especially suitable for embedding \glspl{DSL} but adding user-defined data types is still an issue.
The tagless-final style of embedding offers great modularity, extensibility and flexibility.
However, user-defined data types are awkward to handle because the built-in operations on them---construction, deconstruction and constructor tests---are not inherited from the host language.
By giving an implementation, we showed how to create a \gls{TH} function that will splice the required class definitions and view instances.
repositories / phd-thesis.git / blobdiff