with Class'': TFP 2022.\ Zenodo.\ \url{https://doi.org/10.5281/zenodo.6650880}.}
\section{Deep embedding}
-Pick the language of literal integers and addition \citep{bender_benderrule_2019}\todo{nodig? grappig?}.
+Let us consider the language of literal integers and addition.% \citep{bender_benderrule_2019}.
%Pick a \gls{DSL}, any \gls{DSL}, pick the language of literal integers and addition.
In deep embedding, terms in the language are represented by data in the host language.
-Hence, defining the constructs is as simple as creating the following algebraic data type\footnote{All data types and functions are subscripted to indicate the evolution. When definitions are omitted for version $n$, version $n-1$ is assumed.}.
+Hence, defining the constructs is as simple as creating the following algebraic data type\footnote{All data types and functions are subscripted to indicate the evolution. When definitions are omitted for version $n$, version $n\shortminus{}1$ is assumed.}.
\begin{lstHaskellLhstex}
data Expr_0
eval_0 (Add_0 e1 e2) = eval_0 e1 + eval_0 e2
\end{lstHaskellLhstex}
-Adding semantics---e.g.\ a printer---just means adding another function while the existing functions remain untouched.
-I.e.\ the key property of deep embedding.
+Adding semantics---e.g.\ a printer---just means adding another function while the existing functions remain untouched, i.e.\ the key property of deep embedding.
The following function, transforming the \haskelllhstexinline{Expr_0} data type to a string, defines a simple printer for our language.
\begin{lstHaskellLhstex}
gdict = EvalDict_g eval_g
\end{lstHaskellLhstex}
-Finally, the implementations for the instances can be ported without complication show using the optimisation instance of \haskelllhstexinline{Not_g}:
+Finally, the implementations for the instances can be ported without complication using the optimisation instance of \haskelllhstexinline{Not_g}:
\begin{lstHaskellLhstex}
instance (Typeable d, GDict (d (Not_g d)), HasOpt_g d) => Opt_g (Not_g d) where
Tagless-final embedding is the shallowly embedded counterpart of classy deep embedding and was invented for the same purpose; overcoming the issues with standard shallow embedding \citep{carette_finally_2009}.
Classy deep embedding was organically grown from observing the evolution of tagless-final embedding.
-The main difference between tagless-final embedding and classy deep embedding---and in general between shallow and deep embedding---is that intensional analyses of the abstract syntax tree is more difficult because there is no tangible abstract syntax tree data structure.
+The main difference between tagless-final embedding and classy deep embedding---and in general between shallow and deep embedding---is that intensional analyses of the abstract syntax tree are more difficult because there is no tangible abstract syntax tree data structure.
In classy deep embedding, it is possible to define transformations even across extensions.
Furthermore, in classy deep embedding, defining (mutual) dependent interpretations is automatically supported whereas in tagless-final embedding this requires some amount of code duplication \citep{sun_compositional_2022}.
Intensional analysis is an umbrella term for pattern matching and transformations.
In shallow embedding, intensional analysis is more complex and requires stateful views describing context, but it is possible to implement though.
-Simple type system describes the whether it is possible to encode this embedding technique without many type system extensions.
+Simple type system describes whether it is possible to encode this embedding technique without many type system extensions.
In classy deep embedding, there is either a bit more scaffolding and boilerplate required or advanced type system extensions need to be used.
Minimal boilerplate denotes the amount of scaffolding and boilerplate required.
Classy deep embedding is a novel organically grown embedding technique that alleviates deep embedding from the extensibility problem in most cases.
By abstracting the semantics functions to type classes they become overloaded in the language constructs.
-Thus, making it possible to add new language constructs in a separate type.
+This upgrade makes it possible to add new language constructs in a separate type.
These extensions are brought together in a special extension constructor residing in the main data type.
This extension case is overloaded by the language construct using a data type containing the class dictionary.
As a result, orthogonal extension is possible for language constructs and semantics using only little syntactic overhead or type annotations.
repositories / phd-thesis.git / blobdiff