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 \gls{FP} language are deep embedding (also called initial) and shallow embedding (also called final).
+The two main strategies for embedding \glspl{DSL} in \pgls{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.
The implementation of a view on the \gls{DSL} is achieved by implementing the type classes with the data type representing the view.
In the case of our example \gls{DSL}, an interpreter accounting for failure may be implemented as an instance for the \haskellinline{Maybe} type.
-The standard infix functor application and infix sequential application are used so that potential failure is abstracted away from\footnotemark{}.
+The standard infix functor application and infix sequential application are used so that potential failure is abstracted away from.\footnotemark{}
\begin{lrbox}{\LstBox}
\begin{lstHaskell}[frame=]
<$> :: (a -> b) -> f a -> f b
\subsection{Adding semantics}
To add semantics to the \gls{DSL}, the existing classes are implemented with a novel data type representing the view on the \gls{DSL}.
-First a data type representing the semantics is defined. In this case, the printer is kept very simple for brevity and just defined as a \haskellinline{newtype} of a string to store the printed representation\footnotemark{}.
+First a data type representing the semantics is defined. In this case, the printer is kept very simple for brevity and just defined as a \haskellinline{newtype} of a string to store the printed representation.\footnotemark{}
\footnotetext{%
In this case a \haskellinline{newtype} is used instead of regular \haskellinline{data} declarations.
\haskellinline{newtype}s are special data types only consisting a single constructor with one field to which the type is isomorphic.
infix 1 :-
\end{lstHaskell}
-Using the \haskellinline{Function} type class can be used to define functions with little syntactic overhead\footnote{The \GHCmod{LambdaCase} extension of GHC is used to reduce the number of brackets that allows lambda's to be an argument to a function without brackets or explicit function application using \haskellinline{\$}}.
+Using the \haskellinline{Function} type class can be used to define functions with little syntactic overhead.\footnote{The \GHCmod{LambdaCase} extension of GHC is used to reduce the number of brackets that allows lambda's to be an argument to a function without brackets or explicit function application using \haskellinline{\$}}
The following listing shows an expression in the \gls{DSL} utilising two user-defined functions:
\begin{lstHaskell}
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.
-For the \haskellinline{List} type it is called as: \haskellinline{\$(genDSL ''List)}\footnotemark{}.
+For the \haskellinline{List} type it is called as: \haskellinline{\$(genDSL ''List)}.\footnotemark{}
\footnotetext{
\haskellinline{''} is used instead of \haskellinline{'} to instruct the compiler to look up the information for \haskellinline{List} as a type and not as a constructor.
}
Therefore, the constructor function can be implemented by lifting the actual constructor to the \haskellinline{Maybe} type using sequential application.
I.e.\ for a constructor $C_k$ this results in the following constructor: \haskellinline{ck a0 ... am = pure Ck <*> a0 <*> ... <*> am}.
To avoid accidental shadowing, fresh names for all the arguments are generated.
-The \haskellinline{ifx} function is used as a shorthand for defining infix expressions\footnotemark{}
+The \haskellinline{ifx} function is used as a shorthand for defining infix expressions.\footnotemark{}
\begin{lrbox}{\LstBox}
\begin{lstHaskell}[frame=]
ifx :: String -> Q Exp -> Q Exp -> Q Exp
To avoid accidental shadowing first fresh names for the arguments and fields are generated.
Then, a function is created with the two arguments.
First \haskellinline{d} is evaluated and bound to a host language function that deconstructs the constructor and passes the fields to \haskellinline{f}.
-I.e.\ a deconstructor function $C_k$ is defined as: \haskellinline{unCk d f = d >>= \\(Ck a0 .. am)->f (pure a0) ... (pure am))}\footnotemark{}.
+I.e.\ a deconstructor function $C_k$ is defined as: \haskellinline{unCk d f = d >>= \\(Ck a0 .. am)->f (pure a0) ... (pure am))}.\footnotemark{}
\footnotetext{
The \haskellinline{nameBase :: Name -> String} function from the \gls{TH} library is used to convert a name to a string.
}
repositories / phd-thesis.git / blobdiff