results

[msc-thesis1617.git] / methods.dsl.tex

diff --git a/methods.dsl.tex b/methods.dsl.tex
index 3b4181e..f21cb88 100644 (file)
--- a/methods.dsl.tex
+++ b/methods.dsl.tex
@@ -32,11 +32,11 @@ Evermore so, extending the \gls{ADT} is easy and convenient but extending the
 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.
 
@@ -110,6 +110,9 @@ must be updated accordingly to prevent possible runtime errors. When an
 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
@@ -133,4 +136,15 @@ instance intArith PrettyPrinter where
        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}