An \gls{EDSL} is a language embedded in a host language. \glspl{EDSL} can have
one or more backends or views. Commonly used views are pretty printing,
compiling, simulating, verifying and proving the program. There are several
-techniques available for creating \glspl{EDSL}. Each of them have their own
+techniques available for creating \glspl{EDSL}. They all have their own
advantages and disadvantages in terms of extendability, typedness and view
support. In the following subsections each of the main techniques are briefly
explained.
\section{Deep embedding}
A deep \gls{EDSL} is a language represented as an \gls{ADT}. Views are
functions that transform something to the datatype or the other way around. As
-an example we have the simple arithmetic \gls{EDSL} shown in
+an example, take the simple arithmetic \gls{EDSL} shown in
Listing~\ref{lst:exdeep}.
\begin{lstlisting}[label={lst:exdeep},%
| Eq DSL
\end{lstlisting}
-Deep embedding has the advantage that it is very simple to build and the views
+Deep embedding has the advantage that it is easy to build and views
are easy to add. To the downside, the expressions created with this language
are not type-safe. In the given language it is possible to create an expression
such as \CI{Plus (LitI 4) (LitB True)} that adds a boolean to an integer.
views accordingly is tedious and has to be done individually for all views.
The first downside of this type of \gls{EDSL} can be overcome by using
-\glspl{GADT}\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
+\glspl{GADT}~\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
the same language, but type-safe with a \gls{GADT}. \glspl{GADT} are not
supported in the current version of \gls{Clean} and therefore the syntax is
hypothetical. However, it has been shown that \glspl{GADT} can be simulated
-using bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately
+using bimaps or projection pairs~\cite{cheney_lightweight_2002}. Unfortunately
the lack of extendability remains a problem. If a language construct is added,
no compile time guarantee is given that all views support it.
\end{lstlisting}
\section{Shallow embedding}
-In a shallowly \gls{EDSL} all language constructs are expressed as functions in
-the host language. An evaluator view for our example language then looks
-something like the code shown in Listing~\ref{lst:exshallow}. Note that much of
+In a shallow \gls{EDSL} all language constructs are expressed as functions in
+the host language. An evaluator view for the example language then can be
+implemented as the code shown in Listing~\ref{lst:exshallow}. Note that much of
the internals of the language can be hidden using monads.
\begin{lstlisting}[label={lst:exshallow},%
the language constructs are defined as type classes. This language is shown
with the new method in Listing~\ref{lst:exclassshallow}.
-This type of embedding inherits the easiness of adding views from shallow
+This type of embedding inherits the ease of adding views from shallow
embedding. A view is just a different data type implementing one or more of the
type classes as shown in the aforementioned Listing where an evaluator and a
pretty printer are implemented.
extension is added in a new class, this problem does not arise and views can
choose to implement only parts of the collection of classes.
+In contrast to deep embedding, it is very well possible to have multiple views
+applied on the same expression. This is also shown in the following listing.
+
\begin{lstlisting}[label={lst:exclassshallow},%
caption={A minimal class based shallow \gls{EDSL}}]
:: Env = ... // Some environment
lit x = toString x
add x y = x +++ "+" +++ y
...
+
+...
+
+Start :: (PP String, Bool)
+Start = (print e0, eval e0)
+where
+ e0 :: a Bool | intArith, boolArith a
+ e0 = eq (lit 42) (lit 21 +. lit 21)
+
+ print (PP p) = p
+ eval (Evaluator e) env = e env
\end{lstlisting}
repositories / msc-thesis1617.git / blobdiff