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.
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}