+CmdLine {
+ -v
+}
+VerbEnvir {
+ lstinline lstlisting algorithm code spec lstClean lstHaskell
+}
+WipeArg {
+ \cleaninline:{}
+ \haskellinline:{}
+ \texttt:{}
+ \url:{}
+ \only:{}
+}
+Silent {
+ \pause
+}
+MathEnvir {
+ code
+}
Funding: Teun de Groot, Ton van Heusden
+
Supervisors: Pieter Koopman, Rinus Plasmeijer, Jan-Martin Jansen
-Colleagues: Jurriën Stutterheim, Laszlo Domoslai, Arjan Oortgiese, Bas Lijnse, Steffen Michels, Markus Klinik, Tim Steenvoorden, Camil Staps, Hans-Nikolai Vießmann
-Ralf Hinze, John van Groningen, Sven-Bodo Scholz, Sjaak Smetserrs, Fok Bolderheij
+Colleagues: Jurriën Stutterheim, Laszlo Domoslai, Arjan Oortgiese, Bas Lijnse, Steffen Michels, Markus Klinik, Tim Steenvoorden, Camil Staps, Hans-Nikolai Vie\ss{}mann, John van Groningen, Sven-Bodo Scholz, Sjaak Smetsers, Fok Bolderheij, Simone Meeuwsen, Peter Achten
+
+Co-authors: Jeremy Singer, Phil Trinder, Adrian Ramsigh
\todo{Second assessor clients weglaten?: Willem, Dave, Gijs}
Students: Matheus Amazonas Cabral de Andrade, Haye B\"ohm, Erin van der Veen, Colin de Roos, Willem de Vos, Michel de Boer, Dave Artz, Sjoerd Crooijmans, Gijs Alberts, Arjen Nederveen
+
+Mentors: Jos Baack, Francisco Torreira, Franc Grootjen, the late Louis Vuurpijl, Ralf Hinze
+
+Friends: Pieter Wolfert and Annerieke Wessels; Chris Kamphuis and Maudy Bijen; Koen Dercksen and Michelle Everard; George Gregoire; Larry Caruthers; Tim Hirschler.
+
+Family: Parents (in law), brothers (in law), oma,
+
+Marie-José van Diem
--- /dev/null
+While \gls{CLEAN} and \gls{HASKELL} were both conceived around 1987 and have similar syntax, there are some subtle differences in syntax and functionality.
+This section describes some of the history of \gls{CLEAN} and provides a crash course in \gls{CLEAN} pecularities writen for \gls{HASKELL} programmers.
+
+\Gls{CLEAN}---acronym for Clean \acrlong{LEAN}~\cite{barendregt_towards_1987}---, was originally designed as a \gls{GRS} core language but quickly served as an intermediate language for other functional languages~\cite{brus_clean_1987}.
+In the early days it has also been called \emph{Concurrent} \gls{CLEAN}~\cite{nocker_concurrent_1991} but these days the language has no support for this anymore.
+Fast forward thirty years, \gls{CLEAN} is now a robust language with state-of-the-art features and is actually used in industry as well as academia---albeit in select areas of the world~\cite{plasmeijer_clean_2021}.
+
+Initially, when it was used mostly as an intermediate language, it had a fairly spartan syntax.
+However, over the years, the syntax got friendlier and it currently it looks a lot like \gls{HASKELL}.
+In the past, a \emph{double-edged} fronted even existed that allowed \gls{CLEAN} to be extended with \gls{HASKELL98} syntax and vice versa, however this frontend is no longer maintained~\cite{groningen_exchanging_2010}.
+This chapter therefore gives a brief syntactical and functional comparison, a complete specification of the \gls{CLEAN} language can be found in the latest language report~\cite{plasmeijer_clean_2021}.
+Many of this is based on work by Achten although that was based on \gls{CLEAN} 2.1 and \gls{HASKELL98}~\cite{achten_clean_2007}.
+When \gls{HASKELL} is mentioned I actually mean \gls{GHC}'s \gls{HASKELL} and by \gls{CLEAN} I mean \gls{CLEAN} 3.1's \gls{ITASK} compiler.
+
+\section{Features}
+\subsection{Modules}
+\Gls{CLEAN} has separate implementation and definition modules.
+The definition module contains the class definitions, instances, function types and type definitions (possibly abstract).
+Implementation modules contain the function implementations as well.
+This means that only what is defined in the definition module is exported in \gls{CLEAN}.
+This differs greatly from \gls{HASKELL}, as there is only a module file there.
+Choosing what is exported in \gls{HASKELL} is done using the \haskellinline{module Mod(...)} syntax.
+
+\subsection{Strictness}
+In \gls{CLEAN}, by default, all expressions are evaluated lazily.
+Types can be annotated with a strictness attribute (\cleaninline{!}), resulting in the values being evaluated to head-normal form before the function is entered.
+In \gls{HASKELL}, in patterns, strictness can be enforced using \haskellinline{!}\requiresGHCmod{BangPatterns}.
+Within functions the strict let (\cleaninline{#!}) can be used to force evaluate an expression, in \gls{HASKELL} \haskellinline{seq} or \haskellinline{\$!} is used for this.
+
+\subsection{Uniqueness typing}
+Types in \gls{CLEAN} may be \emph{unique}, which means that they may not be shared\todo{cite}.
+The uniqueness type system allows the compiler to generate efficient code because unique data structures can be destructively updated.
+Furthermore, uniqueness typing serves as a model for side effects as well.
+\Gls{CLEAN} uses the \emph{world-as-value} paradigm where \cleaninline{World} represents the external environment and is always unique.
+A program with side effects is characterised by a \cleaninline{Start :: *World -> *World} start function.
+In \gls{HASKELL}, interaction with the world is done using the \haskellinline{IO} monad.
+The \haskellinline{IO} monad could very well be---and actually is---implemented in \gls{CLEAN} using a state monad with the \cleaninline{World} as a state.
+Besides marking types as unique, it is also possible to mark them with uniqueness attributes variables \cleaninline{u:} and define constraints on them.
+For example, to make sure that an argument of a function is at least as unique as another argument.
+Finally, using \cleaninline{.} (a dot), it is possible to state that several variables are equally unique.
+Uniqueness is propagated automatically in function types but must be marked manually in data types.
+Examples can be seen in \cref{lst:unique_examples}.
+
+\begin{lstClean}[label={lst:unique_examples},caption={Examples of uniqueness annotations}]
+f :: *a -> *a // f works on unique values only
+f :: .a -> .a // f works on unique and non-unique values
+f :: v:a u:b -> u:b, [v<=u] // f works when a is less unique than b
+\end{lstClean}
+%f :: (Int, *World) -> *World // The uniqueness is propagated automatically (i.e. *(Int, *World)))
+%:: T = T *(Int, *World) // Writing :: T = T (Int, *World) won't work
+%:: T = T (Int -> *(*World -> *World)) // Writing :: T = T (Int *World -> *World) won't work
+
+\subsection{Expressions}
+\todo[inline]{Matches pattern expression \texttt{=:}}
+
+\todo[inline]{Let before}
+
+\subsection{Generics}
+Polytypic functions~\cite{jeuring_polytypic_1996}---also known as generic or kind-indexed fuctions---are built into \gls{CLEAN}~\cite[Chp.~7.1]{plasmeijer_clean_2021}\cite{alimarine_generic_2005} whereas in \gls{HASKELL} they are implemented as a library~\cite[Chp.~6.19.1]{ghc_team_ghc_2021}.
+%When calling a generic function, the kind must always be specified and depending on the kind, the function may require more arguments.
+
+For example, defining a generic equality is done as in \cref{lst:generic_eq}.
+\lstinputlisting[language=Clean,firstline=4,label={lst:generic_eq},caption={Generic equality function in \gls{CLEAN}.}.]{lst/generic_eq.icl}
+
+Metadata about the types is available using the \cleaninline{of} syntax that gives the function access to metadata records, as can be seen in \cref{lst:generic_print} showing a generic print function. This abundance of metadata allows for very complex generic functions that near the expression level of template metaprogramming\todo[inline]{crossref chapter c-code generation}.
+\lstinputlisting[language=Clean,firstline=4,label={lst:generic_print},caption={Generic print function in \gls{CLEAN}.}]{lst/generic_print.icl}
+
+\subsection{\glsentrytext{GADT}s}
+GADTs are enriched data types that allow the type instantiation of the constructor to be explicitly defined~\cite{cheney_first-class_2003,hinze_fun_2003}.
+While \glspl{GADT} are not natively supported in \gls{CLEAN}, they can be simulated using embedding-projection pairs or equivalence types~\cite[Sec.~2.2]{cheney_lightweight_2002}.
+To illustrate this, \cref{lst:gadt_clean} shows an example \gls{GADT} that would be implemented in \gls{HASKELL} as done in \cref{lst:gadt_haskell}\requiresGHCmod{GADTs}.
+
+\lstinputlisting[language=Clean,firstline=4,label={lst:gadt_clean},caption={Expression \gls{GADT} using equivalence types in \gls{CLEAN}.}]{lst/expr_gadt.icl}
+\lstinputlisting[language=Haskell,style=haskell,firstline=4,label={lst:gadt_haskell},caption={Expression \gls{GADT} in \gls{HASKELL}.}]{lst/expr_gadt.hs}
+
+\section{Syntax}
+\begin{longtable}{p{.45\linewidth}p{.5\linewidth}}
+ \caption[]{Syntactical differences between \gls{CLEAN} and \gls{HASKELL}.}%
+ \label{tbl:syn_clean_haskell}\\
+ \toprule
+ \gls{CLEAN} & \gls{HASKELL}\\
+ \midrule
+ \endfirsthead%
+ \caption[]{(continued)}\\
+ \toprule
+ \gls{CLEAN} & \gls{HASKELL}\\
+ \midrule
+ \endhead%
+
+ \midrule
+ \multicolumn{2}{c}{Comments}\\
+ \midrule
+ \cleaninline{// single line} & \haskellinline{-- single line}\\
+ \cleaninline{/* multi line /* nested */ */} & \haskellinline{\{- multi line \{- nested -\} \}}\\
+
+ \midrule
+ \multicolumn{2}{c}{Imports}\\
+ \midrule
+ \cleaninline{import Mod => qualified f1, :: t} & \haskellinline{import qualified Mod (f1, t)}\\
+ & \haskellinline{import Mod hiding (f1, t)}\\
+ \cleaninline{/* multi line /* nested */ */} & \haskellinline{\{- multi line \{- nested -\} \}}\\
+
+ \midrule
+ \multicolumn{2}{c}{Basic types}\\
+ \midrule
+ \cleaninline{42 :: Int} & \haskellinline{42 :: Int}\\
+ \cleaninline{True :: Bool} & \haskellinline{True :: Bool}\\
+ \cleaninline{toInteger 42 :: Integer} & \haskellinline{42 :: Integer}\\
+ \cleaninline{38.0 :: Real} & \haskellinline{38.0 :: Float -- or Double}\\
+ \cleaninline{"Hello" +++ "World" :: String}\footnote{Strings are represented as unboxed character arrays.}
+ & \haskellinline{"Hello" ++ "World" :: String}\footnote{Strings are represented as lists of characters by default but may be overloaded as well if \GHCmod{OverloadedStrings} is enabled.}\\
+ \cleaninline{['Hello'] :: [Char]} & \haskellinline{"Hello" :: String}\\
+ \cleaninline{?t} & \haskellinline{Maybe t}\\
+ \cleaninline{(?None, ?Just e)} & \haskellinline{(Nothing, Just e)}\\
+
+ \midrule
+ \multicolumn{2}{c}{Type definitions}\\
+ \midrule
+ \cleaninline{:: T a0 ... :== t} & \haskellinline{type T a0 ... = t}\\
+ \cleaninline{:: T a0 ... } & \haskellinline{data T a1 ...}\\
+ \quad\cleaninline{= C1 f0 ... fn \| ... \| Cn f0 ... fn} & \quad\haskellinline{= C1 f0 ... fn \| ... \| Cn f0 ... fn}\\
+ \cleaninline{:: T a0 ...} & \haskellinline{data T a0 ...}\\
+ \quad\cleaninline{= \{ f0 :: t0, ..., fn :: tn \} } & \quad\haskellinline{= T \{ f0 :: t0, ..., fn :: tn \} }\\
+ \cleaninline{:: T a0 ... =: t} & \haskellinline{newtype T a0 ... = t}\\
+ \cleaninline{:: T = E.t Box t \& C t} & \haskellinline{data T = forall t.C t => Box t}\requiresGHCmod{ExistentialQuantification}\\
+
+ \midrule
+ \multicolumn{2}{c}{Function types}\\
+ \midrule
+ \cleaninline{f0 :: a0 a1 ... -> t}
+ & \haskellinline{f0 :: (c0 v0, c1 v1, c2 v2) =>}\\
+ \quad\cleaninline{\| c0 v0 \& c1, c2 v1}
+ & \quad\haskellinline{a0 -> a1 ... -> t}\\
+ \cleaninline{(+) infixl 6 :: Int Int -> Int} & \haskellinline{infixl 6 +}\\
+ & \haskellinline{(+) :: Int -> Int -> Int}\\
+ \cleaninline{qid :: (A.a: a -> a) -> (Bool, Int)}
+ & \haskellinline{qid :: (forall a: a -> a) -> (Bool, Int)}\requiresGHCmod{RankNTypes}\\
+ \cleaninline{qid id = (id True, id 42)} &
+ \haskellinline{qid id = (id True, id 42)}\\
+
+ \midrule
+ \multicolumn{2}{c}{Type classes}\\
+ \midrule
+ \cleaninline{class f a :: t} & \haskellinline{class f a where f :: t}\\
+ \cleaninline{class C a \| C0, ... , Cn a}\footnote{In contrast to the \gls{HASKELL} variant, this does not require an instance.} & \haskellinline{class (C0 a, ..., Cn, a) => C a}\\
+ \cleaninline{class C s ~m where ...} & \haskellinline{class C s m \| m -> s where ...}\requiresGHCmod{MultiParamTypeClasses}\\
+ \cleaninline{instance C t \| C0, ..., Cn a} & \haskellinline{instance (C0 a, ..., Cn a) => C t}\\
+ \quad\cleaninline{where ...} & \quad\haskellinline{where ...}\\
+
+ \midrule
+ \multicolumn{2}{c}{As pattern}\\
+ \midrule
+ \cleaninline{x=:p} & \haskellinline{x@p}\\
+
+ \midrule
+ \multicolumn{2}{c}{Lists}\\
+ \midrule
+ \cleaninline{[1,2,3]} & \haskellinline{[1,2,3]}\\
+ \cleaninline{[x:xs]} & \haskellinline{x:xs}\\
+ \cleaninline{[e \\\\ e <- xs \| p e]} & \haskellinline{[e \| e <- xs, p e]}\\
+ \cleaninline{[l \\\\ l <- xs, r <- ys]} & \haskellinline{[l \| l <- xs, r <- ys]}\\
+ \cleaninline{[(l, r) \\\\ l <- xs \& r <- ys]} & \haskellinline{[(l, r) \| (l, r) <- zip xs ys]}\\
+ & or \haskellinline{[(l, r) \| l <- xs \| r <- ys]}\requiresGHCmod{ParallelListComp}\\
+
+ \midrule
+ \multicolumn{2}{c}{Lambda expressions}\\
+ \midrule
+ \cleaninline{\\a0 a1 ...->e} or \cleaninline{\\....e} or \cleaninline{\\...=e} & \haskellinline{\\a0 a1 ...->e}\\
+
+ \midrule
+ \multicolumn{2}{c}{Case distinction}\\
+ \midrule
+ \cleaninline{if p e0 e1} & \haskellinline{if p then e0 else e1}\\
+ \cleaninline{case e of p0 -> e0; ...} & \haskellinline{case e of p0 -> e0; ...}\\
+ \quad or \cleaninline{case e of p0 = e0; ...}\\
+ \cleaninline{f p0 ... pn} & \haskellinline{f p0 ... pn}\\
+ \quad\cleaninline{\| c = t} & \quad\haskellinline{\| c = t}\\
+ \quad\cleaninline{\| otherwise = t} or \cleaninline{= t} & \quad\haskellinline{\| otherwise = t}\\
+
+ \midrule
+ \multicolumn{2}{c}{Record expressions}\\
+ \midrule
+ \cleaninline{:: R = \{ f :: t \}} & \haskellinline{data R = R \{ f :: t \}}\\
+ \cleaninline{r = \{ f = e \}} & \haskellinline{r = R \{e\}}\\
+ \cleaninline{r.f} & \haskellinline{f r}\\
+ \cleaninline{r!f}\footnote{This operator allows for field selection from unique records.} & \haskellinline{(\\v->(f v, v)) r}\\
+ \cleaninline{\{r \& f = e \}} & \haskellinline{r \{ f = e \}}\\
+
+ \midrule
+ \multicolumn{2}{c}{Record patterns}\\
+ \midrule
+ \cleaninline{:: R0 = \{ f0 :: R1 \}} & \haskellinline{data R0 = R0 \{ f0 :: R1 \}}\\
+ \cleaninline{:: R1 = \{ f1 :: t \}} & \haskellinline{data R1 = R1 \{ f1 :: t \}}\\
+ \cleaninline{g \{ f0 \} = e f0} & \haskellinline{g (R0 \{f0=x\}) = e x}\\
+ & or \haskellinline{g (R0 \{f0\}) = e f0}\requiresGHCmod{RecordPuns}\\
+ \cleaninline{g \{ f0 = \{f1\} \} = e f1} & \haskellinline{g (R0 \{f0=R1 \{f1=x\}\}) = e x}\\
+
+ \midrule
+ \multicolumn{2}{c}{Arrays}\\
+ \midrule
+ \cleaninline{:: A :== \{t\}} & \haskellinline{type A = Array Int t}\\
+ \cleaninline{a = \{v0, ..., vn\}} & \haskellinline{a = array (0, n+1)}\\
+ & \quad\haskellinline{[(0, v0), ..., (n, vn)]}\\
+ \cleaninline{a = \{e \\\\ p <-: a\}} & \haskellinline{a = array (0, length a-1)}\\
+ & \quad\haskellinline{[e \| (i, a) <- [0..] `zip` a]}\\
+ \cleaninline{a.[i]} & \haskellinline{a!i}\\
+ \cleaninline{a![i]}\footnote{This operator allows for field selection from unique arrays.} & \haskellinline{(\v->(v!i, v)) a}\\
+ \cleaninline{\{ a \& [i] = e\}} & \haskellinline{a//[(i, e)]}\\
+
+ \midrule
+ \multicolumn{2}{c}{Dynamics}\\
+ \midrule
+ \cleaninline{f :: a -> Dynamic \| TC a} & \haskellinline{f :: Typeable a => a -> Dynamic}\\
+ \cleaninline{f e = dynamic e} & \haskellinline{f e = toDyn (e)}\\
+ \cleaninline{g :: Dynamic -> t} & \haskellinline{g :: Dynamic -> t}\\
+ \cleaninline{g (e :: t) = e0} & \haskellinline{g d = case fromDynamic d}\\
+ \cleaninline{g e = e1} & \quad\haskellinline{Just e -> e0}\\
+ & \quad\haskellinline{Nothing -> e1}\\
+
+ \bottomrule
+\end{longtable}
+
\topskip0pt
\vspace*{\fill}
\begin{centering}
- Voor Andries
+ Voor Roos en Lotte
\end{centering}
\vspace*{\fill}
-\chapter{Tagless final embedding}
+\chapter{\Glsentrytext{DSL} techniques}
+\input{domain_specific_languages/dsl_techniques.tex}
+
+\chapter{Tagless-final embedding}
Dit kan ook een section zijn in de volgende chapter, maar toch lijkt het mij nuttig.
-\chapter{Class based deep embedding}
-Pearl
+\chapter{Classy deep embedding}%
+\label{chp:classy deep embedding}
+TFP22/pearl
+
+\chapter{First-class datatypes}
+TFP22
-\chapter{The \gls{MTASK} language}
-RWDSL paper
+\chapter{The \glsentrytext{MTASK} language}
+RWDSL paper\todo{mogelijk naar part twee?}
--- /dev/null
+An \gls{EDSL} is a language embedded in a host language created for a specific domain\todo{citation needed?}.
+\glspl{EDSL} can have one or more backends or views.
+Commonly used views are pretty printing, compiling, simulating, verifying and proving the program.
+Embedding techniques can be characterised by at least the following properties:
+\begin{enumerate}
+ \item Extendibility of constructs
+ \item Extendibility of views
+ \item Type safety, the type of a term in the language is typed in the host language
+ \item Support for well typed variables
+ \item Intensional analyses
+ \item Support for partial views, not all views need to support all constructs
+\end{enumerate}
+
+There are two main techniques for creating embedding \glspl{DSL}, deep---also called tagged---embedding and shallow---also called tagless---embedding.
+In the following sections both techniques are explained.
+As an example, a simple language with integers, booleans and some arithmetic operators is used as a running example.
+
+\section{Deep embedding}
+A deep \gls{EDSL} is a language represented as data in the host language.
+Views are functions that transform \emph{something} to the datatype or the other way around.
+Definition~\ref{lst:exdeep} shows an implementation for the example \gls{DSL}.
+
+\begin{lstHaskell}[label={lst:exdeep},caption={A deeply embedded expression \gls{DSL}.}]
+data Value = I Int | B Bool
+data Expr
+ = Lit Value
+ | Plus Expr Expr
+ | Eq Expr Expr
+ deriving Show
+\end{lstHaskell}
+
+Implementing a printer for the language is straightforward:
+
+\begin{lstHaskell}[caption={A printer for the deeply embedded expression \gls{DSL}.}]
+print :: Expr -> String
+print (Lit i) = show i
+print (Plus l r) = "(" ++ print l ++ "+" ++ print r ++ ")"
+print (Eq l r) = "(" ++ print l ++ "==" ++ print r ++ ")"
+\end{lstHaskell}
+
+Adding a construct, for example subtraction reveals the Achilles' heel of deep embedding, namely that we need to revisit the original data type \emph{and} all the existing views.
+I.e.\ we need to add \haskellinline{| Sub Expr Expr} to the \haskellinline{Expr} data type and \haskellinline{print (Sub l r) = ...} to the \haskellinline{print} view.
+This limitation can be overcome by lifting the views to classes (See \cref{chp:classy deep embedding}).
+
+Implementing an evaluator for the language is possible without touching any original code, we just add a function operating on the \haskellinline{Expr} data type.
+To store variables, it has an extra environment argument\todo{cite while}.
+Here another downside of basic deep embedding arises immediately, the expressions are not typed, and therefore there has to be some type checking in the evaluation code.
+
+\begin{lstHaskell}[]
+eval :: Expr -> Value
+eval (Lit i) = i
+eval (Plus l r) = case (eval l, eval r) of
+ (Lit (I l), Lit (I r)) -> I (l+r))
+ (l, r) -> error $ "Cannot add " ++ show l ++ " to " ++ show r
+eval (Eq l r) = case (eval l, eval r) of
+ (Lit (I l), Lit (I r)) -> B (l==r)
+ (Lit (B l), Lit (B r)) -> B (l==r)
+ (l, r) -> error $ "Cannot compare " ++ show l ++ " to " ++ show r
+\end{lstHaskell}
+
+Luckily this problem can be overcome by switching from regular \glspl{ADT} to \glspl{GADT}, resulting in the following data type and evaluator.
+
+\begin{lstHaskell}[]
+data Expr a where
+ Lit :: Show a => a -> Expr a
+ Plus :: Num a => Expr a -> Expr a -> Expr a
+ Eq :: Eq a => Expr a -> Expr a -> Expr Bool
+
+eval :: Expr a -> a
+eval (Lit i) = i
+eval (Plus l r) = eval l + eval r
+eval (Eq l r) = eval l == eval r
+\end{lstHaskell}
+
+Deep embedding has the advantage that it is easy to build and views are easy to add.
+On the downside, the expressions created with this language are not necessarily type-safe.
+In the given language it is possible to create an expression such as \cleaninline{Plus (LitI 4) (LitB True)} that adds a boolean to an integer.
+Extending the \gls{ADT} is easy and convenient but extending the views accordingly is tedious since it 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}.
+Example~\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_first-class_2003}.
+Unfortunately the lack of extendability remains a problem.
+If a language construct is added, no compile time guarantee can be given that all views support it.
+
+\begin{lstClean}[label={lst:exdeepgadt},caption={A deeply embedded expression \gls{DSL} using \glspl{GADT}.}]
+:: Expr a
+ = Lit a -> Expr a
+ | E.e: Var String -> Expr e
+ | Plus (Expr Int) (Expr Int) -> Expr Int
+ | E.e: Eq (Expr e) (Expr e) -> Expr Bool & == e
+\end{lstClean}
+
+\subsection{Shallow embedding}
+In a shallowly \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 Definition~\ref{lst:exshallow}.
+Note that much of the internals of the language can be hidden using monads.
+
+\begin{lstClean}[label={lst:exshallow}, caption={A minimal shallow \gls{EDSL}.}]
+:: Env :== (String -> Int)
+:: DSL a :== (Env -> a)
+
+Lit :: a -> DSL a
+Lit x = \e->x
+
+Var :: String -> DSL Int
+Var i = \e->retrEnv e i
+
+Plus :: (DSL Int) (DSL Int) -> DSL Int
+Plus x y = \e->x e + y e
+
+Eq :: (DSL a) (DSL a) -> DSL Bool | == a
+Eq x y = \e->x e == y e
+\end{lstClean}
+
+The advantage of shallowly embedding a language in a host language is its extendability.
+It is very easy to add functionality because the compile time checks of the host language guarantee whether or not the functionality is available when used.
+Moreover, the language is type safe as it is directly typed in the host language, i.e.\ \cleaninline{Lit True +. Lit 4} is rejected.
+
+The downside of this method is extending the language with views.
+It is nearly impossible to add views to a shallowly embedded language.
+The only way of achieving this is by reimplementing all functions so that they run all backends at the same time.
+This will mean that every component will have to implement all views rendering it slow for multiple views and complex to implement.
+
+\subsection{\Acrlongpl{GADT}}
+
+\section{Shallow embedding}
+
+\subsection{Tagless-final embedding}
+
+\section{Comparison}
% Acronyms
-\newacronym{IOT}{IoT}{internet of things}
-\newacronym{DSL}{DSL}{domain specific language}
+\newacronym{ADT}{ADT}{algebraic data type}
+\newacronym{DSL}{DSL}{domain-specific language}
\newacronym{EDSL}{eDSL}{embedded \acrshort{DSL}}
+\newacronym{GADT}{GADT}{generalised \acrshort{ADT}}
+\newacronym{GHC}{GHC}{Glasgow Haskell Compiler}
+\newacronym{GPL}{GPL}{general-purpose language}
+\newacronym{FP}{FP}{functional programming}
+\newacronym{GRS}{GRS}{graph rewriting system}
+\newacronym{GUI}{GUI}{graphical \acrlong{UI}}
+\newacronym{IOT}{IoT}{internet of things}
+\newacronym{LEAN}{LEAN}{language of East-Anglia and Nijmegen}
\newacronym{TOP}{TOP}{task-oriented programming}
+\newacronym{TOSD}{TOSD}{task-oriented software development}
+\newacronym{TRS}{TRS}{graph rewriting system}
+\newacronym{RFID}{RFID}{radio-frequency identification}
+\newacronym{SN}{SN}{sensor network}
+\newacronym{BLE}{BLE}{Bluetooth low energy}
+\newacronym{API}{API}{application programming interface}
+\newacronym{OS}{OS}{operating system}
+\newacronym{RTOS}{RTOS}{real-time \acrshort{OS}}
+\newacronym{OTA}{OTA}{over-the-air}
+\newacronym{MCU}{MCU}{microcontroller unit}
+\newacronym{UI}{UI}{user interface}
+\newacronym{SDS}{SDS}{shared data source}
% Glossaries
\newglossaryentry{MTASK}{%
name=iTask,
description={is a \acrshort{TOP} \acrshort{EDSL} for creating distributed multi-user collaborative web applications.},
}
+\newglossaryentry{CLEAN}{%
+ name=Clean,
+ description={Clean \acrlong{LEAN}, a pure lazy functional programming language based on graph rewriting}
+}
+\newglossaryentry{HASKELL}{%
+ name=Haskell,
+ description={is a pure lazy functional programming language designed by a committe as a concept language}
+}
+\newglossaryentry{HASKELL98}{%
+ name=Haskell98,
+ description={is a standardised version of \gls{HASKELL}}
+}
-\section{Background}
-\subsection{\Acrlong{IOT}}
-The \gls{IOT} is \ldots
+The sheer number of connected devices around us is increasing exponentially.
+First and foremost, these devices are driven by software.
+This thesis is about \ldots
+\todo[inline]{introduction}
-\subsection{Functional programming}
-Functional programming is \ldots
+\section{\Acrlong{IOT}}
+\todo[inline]{add more citations and rewrite to make modern}
+The \gls{IOT} is growing rapidly and it is changing the way people and machines interact with the world.
+The term \gls{IOT} was coined around 1999 to describe the communication of \gls{RFID} devices.
+\gls{RFID} became more and more popular the years after but the term \gls{IOT} was not associated with it anymore.
+Years later, during the rise of novel network technologies, the term \gls{IOT} resurged with a slightly different meaning.
+Today, the \gls{IOT} is the term for a system of devices that sense the environment, act upon it and communicate with each other and the world.
+At the time of writing, there is about one connected device per person in the world of which many are part of an \gls{IOT} system.
+Gartner estimates that of these connected devices, there are about $5.8$ billion \gls{IOT} devices or endpoints connected~\footnote{Gartner (August 2019)}\todo[inline]{update with recent number}.
+They are already in everyone's household in the form of smart electricity meters, smart fridges, smartphones, smart watches, home automation and in the form of much more.
+While the number of devices seems to be growing exponentially fast, programming \gls{IOT} applications is difficult.
+The devices are a large heterogeneous collection of different platforms, protocols and languages resulting in impedance problems.
-\subsection{\Acrlong{TOP}}
-\Gls{TOP} is \ldots
+The devices in \gls{IOT} systems are equipped with various sensors and actuators.
+These range from external ones such as positioning, temperature and humidity to more internal ones like heartbeat and respiration.
+When describing \gls{IOT} systems, a layered architecture is often used to compartmentalize the technology.
+For the intents and purposes of this paper the four layer architecture defined by ITU-T (International Telecommunications Union {-} Telecommunication Standardization Sector) will be used as visualized in Figure~\ref{fig:layers}.
-\gls{ITASK} uses generic programming\index{generic programming}
+\begin{figure}
+ \centering
+ \begin{tikzpicture}[node distance=3em]
+ \node (1) [rectangle,draw,minimum width=10em] {Application Layer};
+ \node (2) [rectangle,draw,minimum width=10em,below of=1] {Support Laper};
+ \node (3) [rectangle,draw,minimum width=10em,below of=2] {Network Layer};
+ \node (4) [rectangle,draw,minimum width=10em,below of=3] {Perception Layer};
-\subsection{\Acrlongpl{DSL}}
-\Glspl{DSL} are \ldots
+ \draw [->] (1) -- (2);
+ \draw [->] (2) -- (1);
+ \draw [->] (2) -- (3);
+ \draw [->] (3) -- (2);
+ \draw [->] (3) -- (4);
+ \draw [->] (4) -- (3);
+ \end{tikzpicture}
+ \caption{The four layered \gls{IOT} architecture as described by the ITU-T.}%
+ \label{fig:layers}
+\end{figure}
+
+The first layer is called the perception layer and contains the actual endpoints with their peripherals.
+For example in home automation, the sensors reading the room and the actuators opening the curtains are in the perception layer.
+As a special type of device, it may also contain a \gls{SN}.
+A \gls{SN} is a collection of sensors connected by a mesh network or central hub.
+The network layer is the second layer and it consists of the hardware and software to connect the perception layer to the world.
+In home automation, this layer may consist of a specialized \gls{IOT} technology such as \gls{BLE} or ZigBee but it may also use existing technologies such as WiFi or wired connections.
+The third layer is named support layer and is responsible for the servicing and business rules surrounding the application.
+One of its goals is to provide the \gls{API}, interfaces and data storage.
+In home automation this provides the server storing the data.
+The fourth and final layer in this architecture is the application layer.
+The application layer provides the interaction between the user and the \gls{IOT} system.
+In home automation, this layer contains the apps for to read the measurements and control the devices.
+
+The perception layer often is a heterogeneous collections of microcontrollers, each having their own peculiarities, language of choice and hardware interfaces.
+The hardware needs to be cheap, small-scale and energy efficient.
+As a result, the \glspl{MCU} used to power these devices do not have a lot of computational power, a soup\c{c}on of memory, and little communication bandwidth.
+Typically the devices do not run a full fledged \gls{OS} but a compiled firmware.
+This firmware is often written in an imperative language that needs to be flashed to the program memory.
+It is possible to dynamically send the program to the program memory using \gls{OTA} programming~\cite{baccelli_scripting_2018,baccelli_reprogramming_2018}.
+Program memory typically is flash based and only lasts a couple of thousand writes before it wears out.
+While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent.
+The properties of the device greatly reduce the flexibility for dynamic systems where tasks are created on the fly, executed on demand and require parallel execution.
+These problems can be mitigated by dynamically sending code to be interpreted to the \gls{MCU}.
+With interpretation, a specialized interpreter is flashed in the program memory once that receives the program code to execute at runtime.
+
+\section{\Acrlongpl{DSL}}
+% General
+Programming languages can be divided up into two categories: \glspl{DSL} and \glspl{GPL}\todo{citation needed}.
+Where \glspl{GPL} are not made with a demarcated area in mind, \glspl{DSL} are tailor-made for a specific domain.
+Consequently, writing idiomatic domain-specific code is easy but this may come at the cost of the \gls{DSL} being less expressive to an extent that it may not even be Turing complete.
+\Glspl{DSL} come in two main flavours: standalone and embedded\footnote{Also called external and internal respectively~\cite{fowler_domain-specific_2010}} of which \glspl{EDSL} can again be classified into heterogeneous and homogeneous languages (see \cref{fig:taxonomy_of_dsls} for this taxonomy).
+
+\begin{figure}[ht]
+ \centering
+ \begin{tikzpicture}[nodes={draw,minimum width=7.5em}]
+ \node (dsl) {\gls{DSL}};
+ \node (sta) [below=of dsl,xshift=-3.75em] {standalone};
+ \node (emb) [right=of sta] {embedded};
+ \node (het) [below=of emb,xshift=-3.75em] {heterogeneous};
+ \node (hom) [right=of het] {homogeneous};
+ \draw [->] (dsl) -- (sta);
+ \draw [->] (dsl) -- (emb);
+ \draw [->] (emb) -- (het);
+ \draw [->] (emb) -- (hom);
+ \end{tikzpicture}
+ \caption{Taxonomy of \glspl{DSL} (adapted from Verna~\cite[pg.\ 2]{mernik_extensible_2013})}%
+ \label{fig:taxonomy_of_dsls}
+\end{figure}
+
+DSLs where historically created as standalone languages which means all the machinery is developed solely for the language.
+The advantage of this approach is that the language designer is free to define the syntax and type system of the language as they wish, not being restricted by any constraint.
+Unfortunately it also means that they need to develop a compiler or interpreter for the language to be usable making standalone \glspl{DSL} costly to create.
+Examples of standalone \glspl{DSL} are regular expressions, make, yacc, XML, SQL, \etc.
+
+A radically different approach is embeddding the \gls{DSL} in a host language, i.e.\ \glspl{EDSL}~\cite{hudak_modular_1998}.
+By defining the language as constructs in the host language, much of the machinery is inherited and the cost of creating embedded languages is very low.
+There are however two sides to the this coin.
+If the syntax of the host language is not very flexible, the syntax of the \gls{DSL} may become clumsy.
+Furthermore, errors shown to the programmer may be larded with host language errors, making it difficult for a non-expert of the host language to work with the \gls{DSL}.
+
+Tratt applied a notion from metaprogramming~\cite{sheard_accomplishments_2001} to \glspl{EDSL} to define homogeneity and heterogeneity of \glspl{EDSL} as follows~\cite{tratt_domain_2008}:
+\begin{quote}
+ a homogeneous system is one where all the components are specifically designed to work with each other, whereas in heterogeneous systems at least one of the components is largely, or completely, ignorant of the existence of the other parts of the system.
+\end{quote}
+Homogeneous \glspl{EDSL} are therefore languages that are solely defined as an extension to their host language.
+They often restrict features of the host language to provide a safer interface or capture an idiomatic pattern in the host language for reuse.
+The difference between a library and a homogeneous \glspl{EDSL} is not always clear.
+Examples of homogeneous \glspl{EDSL} are libraries such as ones for \glspl{GUI} creation, LISP's macro system, \etc.
+
+On the other hand, heterogeneous \glspl{EDSL} are languages that are not executed in the host language.
+For example, Elliott et al.\ describe the language Pan, for which the final representation in the host language is a compiler that will, when executed, generate code for a completely different target platform~\cite{elliott_compiling_2003}.
+In fact, \gls{ITASK} and \gls{MTASK} are both heterogeneous \glspl{EDSL}.
+
+\section{\Acrlong{FP}}\label{ssec:functional programming}
+\Gls{FP} is \ldots
+\Gls{FP} languages are naturally suitable as a host language for \gls{DSL} embedding because of their rich type systems and minimal and extensible syntax~\cite{gibbons_functional_2015}.
+
+\section{\Acrlong{TOP}}
+\Gls{TOP} is a declarative programming paradigm designed to model interactive systems~\cite{plasmeijer_task-oriented_2012}.
+Instead of dividing problems up into a layered approach it deals with separation of concerns in a novel way (see \cref{fig:tosd}).
+All components of a \gls{TOP} program are centered around the data types and from these datatypes, implementation details such as the interface, the communication and the sharing of data is generated.
+\begin{description}
+ \item[Data types]
+ In \gls{TOP}, everything is based around datatypes.
+ \item[Tasks]
+ A task is an abstract representation of a piece of work that needs to be done.
+ It provides an intuitive abstraction over work in the real world.
+ Just as with real-life tasks and workflow, tasks can be combined in various ways such as in parallel or in sequence.
+ Furthermore, tasks are observable which means it is possible to observe a --- partial --- result during execution and act upon it by for example starting new tasks.
+ Examples of tasks are filling in a form, sending an email, reading a sensor or even doing a physical task.
+ \item[UI]
+ The \gls{UI} of the system is automatically generated from the representation of the type.
+ For example, in \gls{FP} languages this may be done using generic programming or template metaprogramming whereas in imperative programming languages they may be done using introspection\todo{Do I want this sentence here?}.
+ In many practical \gls{TOP} systems the \gls{UI} can be tweaked afterwards to suit the needs of the application.
+ \item[SDS]
+ Tasks can communicate using task values but this imposes a problem in many collaboration patterns where tasks that are not necessarily related need to share data.
+ Tasks can also share data using \glspl{SDS}.
+ \Glspl{SDS} are an abstraction over any data.
+ An \gls{SDS} can represent typed data stored in a file, a chunk of memory, a database \etc.
+ \Glspl{SDS} can also represent external impure data such as the time, random numbers or sensory data.
+ Similar to tasks, transformation and combination of \glspl{SDS} is possible.
+ \item[PL]
+ \gls{TOP} languages are usually embedded in \gls{FP} languages but not necessarily.
+ The languages in which the \gls{TOP} is hosted provides the integration with the execution platform if there is any.
+ Some host languages also provide the implementations for the tasks and \glspl{SDS}.
+\end{description}
+
+\begin{figure}[ht]
+ \centering
+ \begin{tikzpicture}
+ \pie[%
+ color={red,violet,teal,blue},
+ explode={0.1},
+ hide number,
+ text=inside,
+ rotate=45,
+ radius=2.25,
+ ]{%
+ 25/\textcolor{white}{UI},
+ 25/\textcolor{white}{Tasks},
+ 25/\textcolor{white}{PL},
+ 25/\textcolor{white}{SDS}
+ }
+ \node [draw,fill=yellow,circle]{Types};
+ \end{tikzpicture}
+ \caption{\Gls{TOSD} approach (adapted from Stutterheim et al.~\cite[pg.\ 20]{wang_maintaining_2018})}%
+ \label{fig:tosd}
+\end{figure}
\section{Thesis Outline}
-\todo{reference correct chapters}
+\todo[inline]{reference correct chapters}
Chapters 0 and 0 are based on the paper \emph{A Task-Based \acrshort{DSL} for Microcomputers}~\cite{koopman_task-based_2018}.
Chapters 0 and 0 are based on the Master's thesis and paper \emph{\glst{TOP} and the \glst{IOT}}~\cite{lubbers_task_2017,lubbers_task_2018}.
--- /dev/null
+.comp 920 010111010010000
+.start __expr_gadt_Start
+.depend "_SystemEnumStrict" "20220216025412"
+.depend "_SystemStrictLists" "20220216025412"
+.depend "StdStrictLists" "20220216025412"
+.depend "_SystemEnum" "20220216025412"
+.depend "StdEnum" "20220216025412"
+.depend "StdMisc" "20220216025412"
+.depend "StdFunctions" "20220216025412"
+.depend "StdCharList" "20220216025412"
+.depend "StdTuple" "20220216025412"
+.depend "StdOrdList" "20220216025412"
+.depend "StdList" "20220216025412"
+.depend "StdClass" "20220216025412"
+.depend "StdFile" "20220216025412"
+.depend "StdString" "20220216025412"
+.depend "_SystemArray" "20220216025412"
+.depend "StdArray" "20220216025412"
+.depend "StdChar" "20220216025412"
+.depend "StdReal" "20220216025412"
+.depend "StdInt" "20220216025412"
+.depend "StdOverloaded" "20220216025412"
+.depend "StdBool" "20220216025412"
+.depend "StdEnv" "20220216025412"
+.module m_expr_gadt "expr_gadt" "20220301194916"
+.endinfo
+.impmod _system
+.implab _cycle_in_spine
+.implab _type_error
+.implab _hnf
+.impdesc e_system_dind
+.implab e_system_nind e_system_eaind
+.impdesc e_system_dif
+.implab e_system_nif e_system_eaif
+.implab e_system_sif
+.impdesc e_system_dAP
+.implab e_system_nAP e_system_eaAP
+.implab e_system_sAP
+.impdesc ARRAY
+.impdesc _Nil
+.impdesc _Cons
+.impdesc _Conss
+.implab n_Conss ea_Conss
+.impdesc _Consts
+.implab n_Consts ea_Consts
+.impdesc _Conssts
+.implab n_Conssts ea_Conssts
+.impdesc _Tuple
+.impdesc d_S.1
+.implab n_S.1 ea_S.1
+.impdesc d_S.2
+.implab n_S.2 ea_S.2
+.impdesc d_S.3
+.implab n_S.3 ea_S.3
+.impdesc d_S.4
+.implab n_S.4 ea_S.4
+.impdesc d_S.5
+.implab n_S.5 ea_S.5
+.impdesc d_S.6
+.implab n_S.6 ea_S.6
+.implab _driver
+.impmod StdFunctions
+.impdesc e_StdFunctions_did
+.impmod StdString
+.impdesc e_StdString_dtoString;5
+.impmod StdOverloaded
+.impdesc e_StdOverloaded_d+;.+
+.implab e_StdOverloaded_n+;.+ e_StdOverloaded_ea+;.+
+.impdesc e_StdOverloaded_d==;.==
+.implab e_StdOverloaded_n==;.== e_StdOverloaded_ea==;.==
+.impdesc e_StdOverloaded_rtoString;
+.record r7 aaaa 4 0 "BM"
+.record k13 d{a}aa 3 0 e_StdOverloaded_rtoString; "Lit"
+.impdesc e_StdOverloaded_r+;
+.record k14 d{a}aaa 4 0 e_StdOverloaded_r+; "Add"
+.impdesc e_StdOverloaded_r==;
+.record k15 d{a}aaa 4 0 e_StdOverloaded_r==; "Eq"
+.export __expr_gadt_Start
+.o 0 0
+__expr_gadt_Start
+ build _ 0 n4
+.d 1 0
+ jmp _driver
+.n 0 _
+.o 1 0
+n4
+ push_node _cycle_in_spine 0
+.d 0 0
+ jsr ea4
+.o 0 1 i
+ fillI_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 0 0
+ea4
+.o 0 0
+s4
+ buildh e_StdString_dtoString;5 0
+ create
+ buildI 42
+ push_a 2
+ update_a 2 3
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+.d 3 0
+ jsr s2
+.o 1 0
+.d 1 0
+ jsr s3
+.o 1 0
+ pushI_a 0
+ pop_a 1
+.d 0 1 i
+ rtn
+.o 3 0
+s2
+ build _ 0 n1
+ push_a 2
+ push_a 2
+ push_a 2
+ update_a 2 3
+ update_a 0 2
+ pop_a 1
+ fill_r k13 3 0 5 0 0
+ pop_a 5
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n1
+ push_node _cycle_in_spine 0
+.o 0 0
+ea1
+ buildh e_StdFunctions_did 0
+ buildh e_StdFunctions_did 0
+ buildh e_StdFunctions_did 0
+ buildh e_StdFunctions_did 0
+ fill_r r7 4 0 4 0 0
+ pop_a 4
+.d 1 0
+ rtn
+.n 1 _ _
+.o 1 0
+n3
+ push_node _cycle_in_spine 1
+.d 1 0
+ jsr ea3
+.o 1 0
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.o 1 0
+ea3
+ jsr_eval 0
+.o 1 0
+s3
+ pushD_a 0
+ jmpD ea k14 0 case.2 case.3
+case.1
+ pop_b 1
+ repl_args 3 3
+ pop_a 1
+ jsr_eval 0
+ push_r_args_a 0 4 0 2 1
+ jsr_eval 0
+ push_a 2
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 1 3
+ updatepop_a 0 2
+ jmp_ap 1
+case.2
+ pop_b 1
+ repl_args 4 4
+ push_a 3
+ build _ 1 n3
+ push_a 3
+ build _ 1 n3
+ push_a 2
+ build _ 3 n16
+ jsr_eval 2
+ push_r_args_a 2 4 0 2 1
+ jsr_eval 0
+ update_a 1 5
+ updatepop_a 0 4
+ jmp_ap 1
+case.3
+ pop_b 1
+ repl_args 4 4
+ push_a 3
+ build _ 1 n3
+ push_a 3
+ build _ 1 n3
+ push_a 2
+ build _ 3 n17
+ jsr_eval 2
+ push_r_args_a 2 4 0 2 1
+ jsr_eval 0
+ update_a 1 5
+ updatepop_a 0 4
+ jmp_ap 1
+.n 3 _ ea17
+.o 1 0
+n17
+ push_node _cycle_in_spine 3
+.o 4 0
+ea17
+.o 4 0
+s17
+ push_a 2
+ jsr_eval 0
+ push_a 2
+ jsr_eval 0
+ push_a 2
+ jsr_eval 0
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 3 0
+ jsr_i 2
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.n 3 _ ea16
+.o 1 0
+n16
+ push_node _cycle_in_spine 3
+.o 4 0
+ea16
+.o 4 0
+s16
+ push_a 2
+ jsr_eval 0
+ push_a 2
+ jsr_eval 0
+ push_a 2
+ jsr_eval 0
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 3 0
+ jsr_i 2
+.o 1 0
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
--- /dev/null
+.comp 920 010111010010000
+.start __generic_eq_Start
+.depend "StdGeneric" "20220216025412"
+.depend "_SystemEnumStrict" "20220216025412"
+.depend "_SystemStrictLists" "20220216025412"
+.depend "StdStrictLists" "20220216025412"
+.depend "_SystemEnum" "20220216025412"
+.depend "StdEnum" "20220216025412"
+.depend "StdMisc" "20220216025412"
+.depend "StdFunctions" "20220216025412"
+.depend "StdCharList" "20220216025412"
+.depend "StdTuple" "20220216025412"
+.depend "StdOrdList" "20220216025412"
+.depend "StdList" "20220216025412"
+.depend "StdClass" "20220216025412"
+.depend "StdFile" "20220216025412"
+.depend "StdString" "20220216025412"
+.depend "_SystemArray" "20220216025412"
+.depend "StdArray" "20220216025412"
+.depend "StdChar" "20220216025412"
+.depend "StdReal" "20220216025412"
+.depend "StdInt" "20220216025412"
+.depend "StdOverloaded" "20220216025412"
+.depend "StdBool" "20220216025412"
+.depend "StdEnv" "20220216025412"
+.module m_generic_eq "generic_eq" "20220301120355"
+.endinfo
+.impmod _system
+.implab _cycle_in_spine
+.implab _type_error
+.implab _hnf
+.impdesc e_system_dind
+.implab e_system_nind e_system_eaind
+.impdesc e_system_dif
+.implab e_system_nif e_system_eaif
+.implab e_system_sif
+.impdesc e_system_dAP
+.implab e_system_nAP e_system_eaAP
+.implab e_system_sAP
+.impdesc ARRAY
+.impdesc _Nil
+.impdesc _Cons
+.impdesc _Conss
+.implab n_Conss ea_Conss
+.impdesc _Consts
+.implab n_Consts ea_Consts
+.impdesc _Conssts
+.implab n_Conssts ea_Conssts
+.impdesc _Tuple
+.impdesc d_S.1
+.implab n_S.1 ea_S.1
+.impdesc d_S.2
+.implab n_S.2 ea_S.2
+.impdesc d_S.3
+.implab n_S.3 ea_S.3
+.impdesc d_S.4
+.implab n_S.4 ea_S.4
+.impdesc d_S.5
+.implab n_S.5 ea_S.5
+.impdesc d_S.6
+.implab n_S.6 ea_S.6
+.implab _driver
+.impmod StdChar
+.implab e_StdChar_s==;18
+.impmod StdInt
+.implab e_StdInt_s==;16
+.impdesc e_StdInt_d<;17
+.impmod StdBool
+.implab e_StdBool_s==;3
+.impmod StdGeneric
+.impdesc e_StdGeneric_dUNIT
+.impdesc e_StdGeneric_dLEFT
+.impdesc e_StdGeneric_dRIGHT
+.impdesc e_StdGeneric_dPAIR
+.impdesc e_StdGeneric_dCONS
+.desc d21 _hnf _add_arg 2 0 "C1"
+.desc d22 _hnf _hnf 0 0 "C2"
+.export __generic_eq_Start
+.o 0 0
+__generic_eq_Start
+ build _ 0 n1
+.d 1 0
+ jmp _driver
+.n 0 _
+.o 1 0
+n1
+ push_node _cycle_in_spine 0
+.o 0 0
+ea1
+ buildh _Nil 0
+ buildI 4
+ buildh _Cons 2
+ buildI 3
+ buildh _Cons 2
+ buildI 2
+ buildh _Cons 2
+ buildh _Nil 0
+ buildI 3
+ buildh _Cons 2
+ buildI 2
+ buildh _Cons 2
+ buildI 1
+ buildh _Cons 2
+ buildh e_StdInt_d<;17 0
+ build d10 3 n10
+ buildB TRUE
+ buildh _Just 1
+ buildh _Nil 0
+ buildh _Tuple 2
+ buildI 42
+ buildh d21 2
+ buildh d22 0
+ build _ 2 n11
+ push_a 1
+ push_a 1
+ fillh _Tuple 2 4
+ pop_a 2
+.d 1 0
+ rtn
+.n 2 _
+.o 1 0
+n11
+ push_node _cycle_in_spine 2
+.d 2 0
+ jsr ea11
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 2 0
+ea11
+.o 2 0
+s11
+ push_a 1
+ build _ 1 n15
+ push_a 1
+ build _ 1 n15
+ buildh d47 0
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jmp s6
+.desc d47 _hnf l47 2 0 "_f6"
+.a 2 ea47
+.o 2 0
+l47
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea47
+.o 3 0
+s47
+ push_a 0
+ jsr_eval 0
+ buildh d41 0
+ buildh d46 0
+ push_a 4
+ push_a 3
+ update_a 1 4
+ update_a 2 1
+ update_a 3 2
+ update_a 0 3
+ pop_a 1
+ update_a 3 5
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 4 0
+ jsr s9
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d46 _hnf l46 2 0 "_f5"
+.a 2 ea46
+.o 2 0
+l46
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea46
+.o 3 0
+s46
+ push_a 1
+ jsr_eval 0
+ push_a 1
+ jsr_eval 0
+ buildh d45 0
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jsr s7
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d45 _hnf l45 2 0 "_f4"
+.a 2 ea45
+.o 2 0
+l45
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea45
+.o 3 0
+s45
+ push_a 1
+ jsr_eval 0
+ push_a 1
+ jsr_eval 0
+ buildh d44 0
+ buildh d2 0
+ update_a 3 5
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 4 0
+ jsr s8
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d44 _hnf l44 2 0 "_f3"
+.a 2 ea44
+.o 2 0
+l44
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea44
+.o 3 0
+s44
+ push_a 1
+ jsr_eval 0
+ repl_args 2 2
+ push_a 2
+ jsr_eval 0
+ repl_args 2 2
+ buildh d43 0
+ buildh d42 0
+ update_a 5 7
+ update_a 4 6
+ update_a 3 5
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 6 0
+ jsr s12
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d43 _hnf l43 2 0 "_f2"
+.a 2 ea43
+.o 2 0
+l43
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea43
+.o 3 0
+s43
+ push_a 0
+ jsr_eval 0
+ buildh d3 0
+ push_a 3
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jsr s13
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d42 _hnf l42 2 0 "_f1"
+.a 2 ea42
+.o 2 0
+l42
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea42
+.o 3 0
+s42
+ push_a 0
+ jsr_eval 0
+ buildh d4 0
+ push_a 3
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jsr s10
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d2 _hnf l2 2 0 "gEq_Int;1"
+.o 3 0
+i2
+ pop_a 1
+ jsr_eval 1
+ pushI_a 1
+ jsr_eval 0
+ pushI_a 0
+ pop_a 2
+.d 0 2 ii
+ jmp s2
+.ai 0 a2 i2
+.o 2 0
+l2
+ repl_args 1 1
+.o 2 0
+a2
+.d 2 0
+ jsr ea2
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 2 0
+ea2
+ jsr_eval 1
+ jsr_eval 0
+ pushI_a 1
+ pushI_a 0
+ pop_a 2
+.o 0 2 ii
+s2
+ push_b 1
+ push_b 1
+ update_b 1 3
+ updatepop_b 0 2
+ eqI
+.d 0 1 b
+ rtn
+.desc d4 _hnf l4 2 0 "gEq_Char;4"
+.o 3 0
+i4
+ pop_a 1
+ jsr_eval 1
+ pushC_a 1
+ jsr_eval 0
+ pushC_a 0
+ pop_a 2
+.d 0 2 cc
+ jmp s4
+.ai 0 a4 i4
+.o 2 0
+l4
+ repl_args 1 1
+.o 2 0
+a4
+.d 2 0
+ jsr ea4
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 2 0
+ea4
+ jsr_eval 1
+ jsr_eval 0
+ pushC_a 1
+ pushC_a 0
+ pop_a 2
+.o 0 2 cc
+s4
+ push_b 1
+ push_b 1
+ update_b 1 3
+ updatepop_b 0 2
+ eqC
+.d 0 1 b
+ rtn
+.desc d3 _hnf l3 2 0 "gEq_Bool;2"
+.o 3 0
+i3
+ pop_a 1
+ jsr_eval 1
+ pushB_a 1
+ jsr_eval 0
+ pushB_a 0
+ pop_a 2
+.d 0 2 bb
+ jmp s3
+.ai 0 a3 i3
+.o 2 0
+l3
+ repl_args 1 1
+.o 2 0
+a3
+.d 2 0
+ jsr ea3
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 2 0
+ea3
+ jsr_eval 1
+ jsr_eval 0
+ pushB_a 1
+ pushB_a 0
+ pop_a 2
+.o 0 2 bb
+s3
+ push_b 1
+ push_b 1
+ update_b 1 3
+ updatepop_b 0 2
+ eqB
+.d 0 1 b
+ rtn
+.o 3 0
+s13
+ push_a 2
+ build _ 1 n17
+ push_a 2
+ build _ 1 n17
+ buildh d41 0
+ push_a 3
+ buildh d7 1
+ buildh d9 2
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 3 0
+ jmp s6
+.n 1 _ ea17
+.o 1 0
+n17
+ push_node _cycle_in_spine 1
+.o 2 0
+ea17
+ jsr_eval 0
+.o 2 0
+s17
+ eq_desc _Just 1 0
+ jmp_true case.1
+ jmp case.2
+case.1
+ repl_args 1 1
+ push_a 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dLEFT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+case.2
+ buildh e_StdGeneric_dUNIT 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dRIGHT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+.o 6 0
+s12
+ push_a 5
+ push_a 5
+ buildh _Tuple 2
+ build _ 1 n16
+ push_a 4
+ push_a 4
+ buildh _Tuple 2
+ build _ 1 n16
+ push_a 3
+ push_a 3
+ buildh d8 2
+ buildh d7 1
+ update_a 2 8
+ update_a 1 7
+ updatepop_a 0 6
+.d 3 0
+ jmp s6
+.n 1 _ ea16
+.o 1 0
+n16
+ push_node _cycle_in_spine 1
+.o 2 0
+ea16
+ jsr_eval 0
+ repl_args 2 2
+.o 3 0
+s16
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ fillh e_StdGeneric_dCONS 1 3
+ pop_a 2
+.d 1 0
+ rtn
+.n 1 _ ea15
+.o 1 0
+n15
+ push_node _cycle_in_spine 1
+.o 2 0
+ea15
+ jsr_eval 0
+.o 2 0
+s15
+ eq_desc d21 2 0
+ jmp_true case.3
+ jmp case.4
+case.3
+ repl_args 2 2
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dLEFT 1 3
+ pop_a 2
+.d 1 0
+ rtn
+case.4
+ buildh e_StdGeneric_dUNIT 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dRIGHT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+.desc d10 n10 l10 3 0 "gEq__List;12"
+.o 4 0
+i10
+ pop_a 1
+ jsr_eval 1
+.d 3 0
+ jmp s10
+.ai 0 a10 i10
+.o 2 0
+l10
+ repl_args 2 2
+.o 3 0
+a10
+.d 3 0
+ jsr ea10
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.n 3 d10
+.o 1 0
+n10
+ push_node _cycle_in_spine 3
+.d 3 0
+ jsr ea10
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 3 0
+ea10
+ jsr_eval 1
+.o 3 0
+s10
+ push_a 2
+ build _ 1 n14
+ push_a 2
+ build _ 1 n14
+ buildh d41 0
+ push_a 3
+ buildh d10 1
+ push_a 4
+ buildh d8 2
+ buildh d7 1
+ buildh d9 2
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 3 0
+ jmp s6
+.desc d41 _hnf l41 2 0 "_f0"
+.a 2 ea41
+.o 2 0
+l41
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea41
+.o 3 0
+s41
+ push_a 1
+ jsr_eval 0
+ push_a 1
+ jsr_eval 0
+ buildh d5 0
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jsr s7
+.o 0 1 b
+ fillB_b 0 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d8 _hnf l8 4 0 "gEq_PAIR;10"
+.a 0 a8
+.o 2 0
+l8
+ repl_args 3 3
+.o 4 0
+a8
+.d 4 0
+ jsr ea8
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 4 0
+ea8
+ jsr_eval 3
+ jsr_eval 2
+ jsr_eval 0
+.o 4 0
+s8
+ push_args 2 2 2
+ buildh _Nil 0
+ update_a 0 5
+ pop_a 1
+ push_args 5 2 2
+ buildh _Nil 0
+ update_a 0 8
+ pop_a 1
+ push_a 0
+ push_a 3
+ push_a 6
+ update_a 8 10
+ update_a 6 9
+ update_a 4 8
+ update_a 2 7
+ update_a 1 6
+ updatepop_a 0 5
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+ jmp_false else.5
+ push_a 0
+ push_a 3
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+.d 0 1 b
+ rtn
+else.5
+ pop_a 3
+ pushB FALSE
+.d 0 1 b
+ rtn
+.desc d5 _hnf l5 2 0 "gEq_UNIT;5"
+.a 0 a5
+.o 2 0
+l5
+ repl_args 1 1
+.o 2 0
+a5
+.o 2 0
+ea5
+ pop_a 2
+ pushB TRUE
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.desc d7 _hnf l7 3 0 "gEq_CONS;7"
+.a 0 a7
+.o 2 0
+l7
+ repl_args 2 2
+.o 3 0
+a7
+.d 3 0
+ jsr ea7
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 3 0
+ea7
+ jsr_eval 2
+ jsr_eval 1
+ jsr_eval 0
+.o 3 0
+s7
+ push_args 1 1 1
+ buildh _Nil 0
+ update_a 0 3
+ pop_a 1
+ push_args 3 1 1
+ buildh _Nil 0
+ update_a 0 5
+ pop_a 1
+ push_a 0
+ push_a 2
+ push_a 4
+ update_a 2 7
+ update_a 1 6
+ updatepop_a 0 5
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+.d 0 1 b
+ rtn
+.desc d9 _hnf l9 4 0 "gEq_EITHER;11"
+.a 0 a9
+.o 2 0
+l9
+ repl_args 3 3
+.o 4 0
+a9
+.d 4 0
+ jsr ea9
+.o 0 1 b
+ buildB_b 0
+ pop_b 1
+.d 1 0
+ rtn
+.o 4 0
+ea9
+ jsr_eval 2
+.o 4 0
+s9
+ eq_desc e_StdGeneric_dLEFT 1 2
+ jmp_true case.6
+ jmp case.7
+case.6
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ jsr_eval 4
+ eq_desc e_StdGeneric_dLEFT 1 4
+ jmp_true case.9
+ pop_a 1
+ jmp case.8
+case.9
+ push_args 4 1 1
+ buildh _Nil 0
+ update_a 0 6
+ pop_a 1
+ push_a 0
+ push_a 3
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 8
+ update_a 1 7
+ updatepop_a 0 6
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+.d 0 1 b
+ rtn
+case.7
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ jsr_eval 4
+ eq_desc e_StdGeneric_dRIGHT 1 4
+ jmp_true case.10
+ pop_a 1
+ jmp case.8
+case.10
+ push_args 4 1 1
+ buildh _Nil 0
+ update_a 0 6
+ pop_a 1
+ push_a 0
+ push_a 4
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 8
+ update_a 1 7
+ updatepop_a 0 6
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+.d 0 1 b
+ rtn
+case.8
+ pop_a 4
+ pushB FALSE
+.d 0 1 b
+ rtn
+.n 1 _ ea14
+.o 1 0
+n14
+ push_node _cycle_in_spine 1
+.o 2 0
+ea14
+ jsr_eval 0
+.o 2 0
+s14
+ eq_desc _Cons 2 0
+ jmp_true case.11
+ jmp case.12
+case.11
+ repl_args 2 2
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dLEFT 1 3
+ pop_a 2
+.d 1 0
+ rtn
+case.12
+ buildh e_StdGeneric_dUNIT 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dRIGHT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+.o 3 0
+s6
+ push_a 2
+ push_a 2
+ push_a 2
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ pushB_a 0
+ pop_a 1
+.d 0 1 b
+ rtn
--- /dev/null
+.comp 920 010111010010000
+.start __generic_print_Start
+.depend "StdGeneric" "20220216025412"
+.depend "_SystemEnumStrict" "20220216025412"
+.depend "_SystemStrictLists" "20220216025412"
+.depend "StdStrictLists" "20220216025412"
+.depend "_SystemEnum" "20220216025412"
+.depend "StdEnum" "20220216025412"
+.depend "StdMisc" "20220216025412"
+.depend "StdFunctions" "20220216025412"
+.depend "StdCharList" "20220216025412"
+.depend "StdTuple" "20220216025412"
+.depend "StdOrdList" "20220216025412"
+.depend "StdList" "20220216025412"
+.depend "StdClass" "20220216025412"
+.depend "StdFile" "20220216025412"
+.depend "StdString" "20220216025412"
+.depend "_SystemArray" "20220216025412"
+.depend "StdArray" "20220216025412"
+.depend "StdChar" "20220216025412"
+.depend "StdReal" "20220216025412"
+.depend "StdInt" "20220216025412"
+.depend "StdOverloaded" "20220216025412"
+.depend "StdBool" "20220216025412"
+.depend "StdEnv" "20220216025412"
+.module m_generic_print "generic_print" "20220301120244"
+.endinfo
+.impmod _system
+.implab _cycle_in_spine
+.implab _type_error
+.implab _hnf
+.impdesc e_system_dind
+.implab e_system_nind e_system_eaind
+.impdesc e_system_dif
+.implab e_system_nif e_system_eaif
+.implab e_system_sif
+.impdesc e_system_dAP
+.implab e_system_nAP e_system_eaAP
+.implab e_system_sAP
+.impdesc ARRAY
+.impdesc _Nil
+.impdesc _Cons
+.impdesc _Conss
+.implab n_Conss ea_Conss
+.impdesc _Consts
+.implab n_Consts ea_Consts
+.impdesc _Conssts
+.implab n_Conssts ea_Conssts
+.impdesc _Tuple
+.impdesc d_S.1
+.implab n_S.1 ea_S.1
+.impdesc d_S.2
+.implab n_S.2 ea_S.2
+.impdesc d_S.3
+.implab n_S.3 ea_S.3
+.impdesc d_S.4
+.implab n_S.4 ea_S.4
+.impdesc d_S.5
+.implab n_S.5 ea_S.5
+.impdesc d_S.6
+.implab n_S.6 ea_S.6
+.implab _driver
+.impmod StdString
+.impdesc e_StdString_dtoString;5
+.implab e_StdString_ntoString;5
+.impdesc e_StdString_dtoString;7
+.implab e_StdString_ntoString;7
+.impmod StdGeneric
+.impdesc e_StdGeneric_dUNIT
+.impdesc e_StdGeneric_dLEFT
+.impdesc e_StdGeneric_dRIGHT
+.impdesc e_StdGeneric_dPAIR
+.impdesc e_StdGeneric_dCONS
+.impdesc e_StdGeneric_dRECORD
+.impdesc e_StdGeneric_rGenericTypeDefDescriptor
+.impdesc e_StdGeneric_rGenericConsDescriptor
+.impdesc e_StdGeneric_dGenericConsDescriptor.gcd_name
+.implab e_StdGeneric_nGenericConsDescriptor.gcd_name
+.impdesc e_StdGeneric_dGenConsNoPrio
+.impdesc e_StdGeneric_rGenericRecordDescriptor
+.impdesc e_StdGeneric_rGenericFieldDescriptor
+.impdesc e_StdGeneric_dGenericFieldDescriptor.gfd_name
+.implab e_StdGeneric_nGenericFieldDescriptor.gfd_name
+.impdesc e_StdGeneric_dGenTypeCons
+.impdesc e_StdGeneric_kGenTypeVar
+.impdesc e_StdGeneric_dGenTypeApp
+.impdesc e_StdGeneric_dGenTypeArrow
+.record r42 aa 2 0 "T"
+.export __generic_print_Start
+.o 0 0
+__generic_print_Start
+ build _ 0 n1
+.d 1 0
+ jmp _driver
+.n 0 _ ea1
+.o 1 0
+n1
+ push_node _cycle_in_spine 0
+.o 1 0
+ea1
+.o 1 0
+s1
+ buildh _Nil 0
+ buildh _Nil 0
+ buildh _None 0
+ buildh _Cons 2
+ buildR 3.14
+ buildh _Tuple 2
+ buildI 42
+.d 4 0
+ jmp s14
+.o 4 0
+s14
+ create
+ push_a 2
+ push_a 2
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 3 0
+ jsr s39
+.o 1 0
+ buildh d65 0
+ build _ 0 n38
+ buildh d8 2
+ buildh d2 0
+ build _ 0 n37
+ buildh d8 2
+ buildh d9 2
+ build _ 0 n36
+ push_a 3
+ push_a 3
+ update_a 1 4
+ update_a 2 1
+ update_a 3 2
+ update_a 0 3
+ pop_a 1
+ update_a 3 4
+ update_a 2 3
+ update_a 1 2
+ updatepop_a 0 1
+.d 5 0
+ jmp s7
+.desc d65 _hnf l65 2 0 "_f2"
+.a 2 ea65
+.o 2 0
+l65
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea65
+.o 3 0
+s65
+ push_a 0
+ jsr_eval 0
+ repl_args 2 2
+ buildh d64 0
+ buildh d3 0
+ push_a 5
+ push_a 4
+ update_a 1 5
+ update_a 2 1
+ update_a 3 2
+ update_a 4 3
+ update_a 0 4
+ pop_a 1
+ update_a 4 6
+ update_a 3 5
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 6 0
+ jmp s11
+.desc d64 _hnf l64 2 0 "_f1"
+.a 2 ea64
+.o 2 0
+l64
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea64
+.o 3 0
+s64
+ push_a 0
+ jsr_eval 0
+ buildh d63 0
+ push_a 3
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 4 0
+ jmp s12
+.desc d63 _hnf l63 2 0 "_f0"
+.a 2 ea63
+.o 2 0
+l63
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea63
+.o 3 0
+s63
+ push_a 0
+ jsr_eval 0
+ buildh d2 0
+ push_a 3
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 4
+ update_a 1 3
+ updatepop_a 0 2
+.d 4 0
+ jmp s13
+.n 0 _
+.o 1 0
+n37
+ push_node _cycle_in_spine 0
+.o 0 0
+ea37
+ build _ 0 n36
+ buildI 0
+ buildAC "f1"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericFieldDescriptor 3 0 3 0 0
+ pop_a 3
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n38
+ push_node _cycle_in_spine 0
+.o 0 0
+ea38
+ build _ 0 n36
+ buildI 1
+ buildAC "f2"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericFieldDescriptor 3 0 3 0 0
+ pop_a 3
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n36
+ push_node _cycle_in_spine 0
+.o 0 0
+ea36
+ build _ 0 n35
+ build _ 0 n34
+ buildI 0
+ buildI 2
+ buildAC "T"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericRecordDescriptor 5 0 5 0 0
+ pop_a 5
+.d 1 0
+ rtn
+.n 0 _ ea34
+.o 1 0
+n34
+ push_node _cycle_in_spine 0
+.o 1 0
+ea34
+.o 1 0
+s34
+ buildAC "T"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildAC "Int"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildAC "_!Maybe"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildAC "_List"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildAC "Real"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildAC "_Tuple2"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildh e_StdGeneric_dGenTypeArrow 2
+ buildAC "Int"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ fillh e_StdGeneric_dGenTypeArrow 2 2
+.d 1 0
+ rtn
+.n 0 _ ea35
+.o 1 0
+n35
+ push_node _cycle_in_spine 0
+.o 1 0
+ea35
+.o 1 0
+s35
+ buildh _Nil 0
+ buildAC "f2"
+ buildh ARRAY 1
+ buildh _Cons 2
+ buildAC "f1"
+ buildh ARRAY 1
+ fillh _Cons 2 2
+.d 1 0
+ rtn
+.desc d3 _hnf l3 2 0 "gPrint_Real;3"
+.o 4 0
+i3
+ pop_a 1
+.d 3 0
+ jmp s3
+.ai 2 ea3 i3
+.o 2 0
+l3
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea3
+.o 3 0
+s3
+ push_a 0
+ build _ 1 e_StdString_ntoString;7
+ push_a 2
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ fillh _Cons 2 4
+ pop_a 2
+.d 1 0
+ rtn
+.desc d2 _hnf l2 2 0 "gPrint_Int;1"
+.o 4 0
+i2
+ pop_a 1
+.d 3 0
+ jmp s2
+.ai 2 ea2 i2
+.o 2 0
+l2
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea2
+.o 3 0
+s2
+ push_a 0
+ build _ 1 e_StdString_ntoString;5
+ push_a 2
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ fillh _Cons 2 4
+ pop_a 2
+.d 1 0
+ rtn
+.o 4 0
+s13
+ push_a 1
+ build _ 1 n33
+ buildh d4 0
+ build _ 0 n32
+ buildh d6 2
+ build _ 0 n31
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ buildh d6 2
+ buildh d10 2
+ push_a 4
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 4 0
+ jmp s5
+.n 0 _
+.o 1 0
+n31
+ push_node _cycle_in_spine 0
+.o 0 0
+ea31
+ build _ 0 n29
+ build _ 0 n28
+ buildh e_StdGeneric_dGenConsNoPrio 0
+ buildI 0
+ buildI 1
+ buildAC "_!Just"
+ buildh ARRAY 1
+ push_a 5
+ update_a 3 6
+ update_a 4 3
+ update_a 5 4
+ update_a 0 5
+ pop_a 1
+ fill_r e_StdGeneric_rGenericConsDescriptor 6 0 6 0 0
+ pop_a 6
+.d 1 0
+ rtn
+.n 0 _ ea27
+.o 1 0
+n27
+ push_node _cycle_in_spine 0
+.o 1 0
+ea27
+.o 1 0
+s27
+ buildh _Nil 0
+ build _ 0 n32
+ buildh _Cons 2
+ build _ 0 n31
+ fillh _Cons 2 2
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n28
+ push_node _cycle_in_spine 0
+.o 0 0
+ea28
+ build _ 0 n27
+ buildI 2
+ buildI 1
+ buildAC "_!Maybe"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericTypeDefDescriptor 4 0 4 0 0
+ pop_a 4
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n32
+ push_node _cycle_in_spine 0
+.o 0 0
+ea32
+ build _ 0 n30
+ build _ 0 n28
+ buildh e_StdGeneric_dGenConsNoPrio 0
+ buildI 1
+ buildI 0
+ buildAC "_!None"
+ buildh ARRAY 1
+ push_a 5
+ update_a 3 6
+ update_a 4 3
+ update_a 5 4
+ update_a 0 5
+ pop_a 1
+ fill_r e_StdGeneric_rGenericConsDescriptor 6 0 6 0 0
+ pop_a 6
+.d 1 0
+ rtn
+.n 0 _ ea29
+.o 1 0
+n29
+ push_node _cycle_in_spine 0
+.o 1 0
+ea29
+.o 1 0
+s29
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_!Maybe"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ fillh e_StdGeneric_dGenTypeArrow 2 2
+.d 1 0
+ rtn
+.n 0 _ ea30
+.o 1 0
+n30
+ push_node _cycle_in_spine 0
+.o 1 0
+ea30
+.o 1 0
+s30
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_!Maybe"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ fillh e_StdGeneric_dGenTypeApp 2 2
+.d 1 0
+ rtn
+.n 1 _ ea33
+.o 1 0
+n33
+ push_node _cycle_in_spine 1
+.o 2 0
+ea33
+.o 2 0
+s33
+ eq_desc _Just 1 0
+ jmp_true case.1
+ jmp case.2
+case.1
+ repl_args 1 1
+ push_a 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dLEFT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+case.2
+ buildh e_StdGeneric_dUNIT 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dRIGHT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+.desc d12 _hnf l12 3 0 "gPrint__List;13"
+.o 5 0
+i12
+ pop_a 1
+ jsr_eval 1
+.d 4 0
+ jmp s12
+.ai 3 ea12 i12
+.o 2 0
+l12
+ push_args 0 2 2
+ update_a 3 2
+ create
+ update_a 0 4
+ pop_a 1
+.o 4 0
+ea12
+ jsr_eval 1
+.o 4 0
+s12
+ push_a 1
+ build _ 1 n26
+ buildh d4 0
+ build _ 0 n25
+ buildh d6 2
+ push_a 2
+ buildh d12 1
+ push_a 3
+ buildh d9 2
+ build _ 0 n24
+ buildh d6 2
+ buildh d10 2
+ push_a 4
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+.d 4 0
+ jmp s5
+.n 0 _
+.o 1 0
+n24
+ push_node _cycle_in_spine 0
+.o 0 0
+ea24
+ build _ 0 n22
+ build _ 0 n21
+ buildh e_StdGeneric_dGenConsNoPrio 0
+ buildI 0
+ buildI 2
+ buildAC "_Cons"
+ buildh ARRAY 1
+ push_a 5
+ update_a 3 6
+ update_a 4 3
+ update_a 5 4
+ update_a 0 5
+ pop_a 1
+ fill_r e_StdGeneric_rGenericConsDescriptor 6 0 6 0 0
+ pop_a 6
+.d 1 0
+ rtn
+.n 0 _ ea20
+.o 1 0
+n20
+ push_node _cycle_in_spine 0
+.o 1 0
+ea20
+.o 1 0
+s20
+ buildh _Nil 0
+ build _ 0 n25
+ buildh _Cons 2
+ build _ 0 n24
+ fillh _Cons 2 2
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n21
+ push_node _cycle_in_spine 0
+.o 0 0
+ea21
+ build _ 0 n20
+ buildI 2
+ buildI 1
+ buildAC "_List"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericTypeDefDescriptor 4 0 4 0 0
+ pop_a 4
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n25
+ push_node _cycle_in_spine 0
+.o 0 0
+ea25
+ build _ 0 n23
+ build _ 0 n21
+ buildh e_StdGeneric_dGenConsNoPrio 0
+ buildI 1
+ buildI 0
+ buildAC "_Nil"
+ buildh ARRAY 1
+ push_a 5
+ update_a 3 6
+ update_a 4 3
+ update_a 5 4
+ update_a 0 5
+ pop_a 1
+ fill_r e_StdGeneric_rGenericConsDescriptor 6 0 6 0 0
+ pop_a 6
+.d 1 0
+ rtn
+.n 0 _ ea22
+.o 1 0
+n22
+ push_node _cycle_in_spine 0
+.o 1 0
+ea22
+.o 1 0
+s22
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_List"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_List"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildh e_StdGeneric_dGenTypeArrow 2
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ fillh e_StdGeneric_dGenTypeArrow 2 2
+.d 1 0
+ rtn
+.n 0 _ ea23
+.o 1 0
+n23
+ push_node _cycle_in_spine 0
+.o 1 0
+ea23
+.o 1 0
+s23
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_List"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ fillh e_StdGeneric_dGenTypeApp 2 2
+.d 1 0
+ rtn
+.desc d4 _hnf l4 2 0 "gPrint_UNIT;5"
+.a 2 ea4
+.o 2 0
+l4
+ push_args 0 1 1
+ update_a 2 1
+ create
+ update_a 0 3
+ pop_a 1
+.o 3 0
+ea4
+ jsr_eval 1
+.o 3 0
+s4
+ fill_a 1 2
+ pop_a 2
+.d 1 0
+ rtn
+.desc d10 _hnf l10 4 0 "gPrint_EITHER;11"
+.a 4 ea10
+.o 2 0
+l10
+ push_args 0 3 3
+ update_a 4 3
+ create
+ update_a 0 5
+ pop_a 1
+.o 5 0
+ea10
+ jsr_eval 2
+.o 5 0
+s10
+ eq_desc e_StdGeneric_dLEFT 1 2
+ jmp_true case.3
+ jmp case.4
+case.3
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ push_a 4
+ push_a 2
+ jsr_eval 0
+ push_a 2
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 7
+ update_a 1 6
+ updatepop_a 0 5
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+case.4
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ push_a 4
+ push_a 3
+ jsr_eval 0
+ push_a 2
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 7
+ update_a 1 6
+ updatepop_a 0 5
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.n 1 _ ea26
+.o 1 0
+n26
+ push_node _cycle_in_spine 1
+.o 2 0
+ea26
+.o 2 0
+s26
+ eq_desc _Cons 2 0
+ jmp_true case.5
+ jmp case.6
+case.5
+ repl_args 2 2
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dLEFT 1 3
+ pop_a 2
+.d 1 0
+ rtn
+case.6
+ buildh e_StdGeneric_dUNIT 0
+ buildh e_StdGeneric_dCONS 1
+ fillh e_StdGeneric_dRIGHT 1 2
+ pop_a 1
+.d 1 0
+ rtn
+.o 6 0
+s11
+ push_a 3
+ push_a 3
+ buildh _Tuple 2
+ build _ 1 n19
+ push_a 2
+ push_a 2
+ buildh d9 2
+ build _ 0 n18
+ buildh d6 2
+ push_a 6
+ push_a 2
+ update_a 1 3
+ update_a 2 1
+ update_a 0 2
+ pop_a 1
+ update_a 2 7
+ update_a 1 6
+ updatepop_a 0 5
+.d 4 0
+ jmp s5
+.n 0 _ ea15
+.o 1 0
+n15
+ push_node _cycle_in_spine 0
+.o 1 0
+ea15
+.o 1 0
+s15
+ buildh _Nil 0
+ build _ 0 n18
+ fillh _Cons 2 2
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n16
+ push_node _cycle_in_spine 0
+.o 0 0
+ea16
+ build _ 0 n15
+ buildI 1
+ buildI 2
+ buildAC "_Tuple2"
+ buildh ARRAY 1
+ fill_r e_StdGeneric_rGenericTypeDefDescriptor 4 0 4 0 0
+ pop_a 4
+.d 1 0
+ rtn
+.n 0 _
+.o 1 0
+n18
+ push_node _cycle_in_spine 0
+.o 0 0
+ea18
+ build _ 0 n17
+ build _ 0 n16
+ buildh e_StdGeneric_dGenConsNoPrio 0
+ buildI 0
+ buildI 2
+ buildAC "_Tuple2"
+ buildh ARRAY 1
+ push_a 5
+ update_a 3 6
+ update_a 4 3
+ update_a 5 4
+ update_a 0 5
+ pop_a 1
+ fill_r e_StdGeneric_rGenericConsDescriptor 6 0 6 0 0
+ pop_a 6
+.d 1 0
+ rtn
+.n 0 _ ea17
+.o 1 0
+n17
+ push_node _cycle_in_spine 0
+.o 1 0
+ea17
+.o 1 0
+s17
+ pushI 1
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildAC "_Tuple2"
+ buildh ARRAY 1
+ buildh e_StdGeneric_dGenTypeCons 1
+ buildh e_StdGeneric_dGenTypeApp 2
+ buildh e_StdGeneric_dGenTypeApp 2
+ pushI 1
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ buildh e_StdGeneric_dGenTypeArrow 2
+ pushI 0
+ buildhr e_StdGeneric_kGenTypeVar 0 1
+ fillh e_StdGeneric_dGenTypeArrow 2 2
+.d 1 0
+ rtn
+.desc d6 _hnf l6 4 0 "gPrint_CONS;7"
+.a 4 ea6
+.o 2 0
+l6
+ push_args 0 3 3
+ update_a 4 3
+ create
+ update_a 0 5
+ pop_a 1
+.o 5 0
+ea6
+ jsr_eval 2
+.o 5 0
+s6
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ push_a 4
+ buildAC ")"
+ buildh ARRAY 1
+ buildh _Cons 2
+ push_a 1
+ push_a 4
+ build _ 3 n66
+ buildAC " "
+ buildh ARRAY 1
+ buildh _Cons 2
+ push_a 2
+ build e_StdGeneric_dGenericConsDescriptor.gcd_name -4 e_StdGeneric_nGenericConsDescriptor.gcd_name
+ buildh _Cons 2
+ buildAC "("
+ buildh ARRAY 1
+ fillh _Cons 2 7
+ pop_a 5
+.d 1 0
+ rtn
+.n 3 _ ea66
+.o 1 0
+n66
+ push_node _cycle_in_spine 3
+.o 4 0
+ea66
+.o 4 0
+s66
+ push_a 2
+ push_a 1
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.n 1 _ ea19
+.o 1 0
+n19
+ push_node _cycle_in_spine 1
+.o 2 0
+ea19
+ repl_args 2 2
+.o 3 0
+s19
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ fillh e_StdGeneric_dCONS 1 3
+ pop_a 2
+.d 1 0
+ rtn
+.o 4 0
+s5
+ push_a 2
+ push_a 2
+ push_a 2
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.desc d8 _hnf l8 4 0 "gPrint_FIELD;9"
+.a 4 ea8
+.o 2 0
+l8
+ push_args 0 3 3
+ update_a 4 3
+ create
+ update_a 0 5
+ pop_a 1
+.o 5 0
+ea8
+.o 5 0
+s8
+ push_a 3
+ push_a 3
+ push_a 3
+ build _ 3 n67
+ buildAC "="
+ buildh ARRAY 1
+ buildh _Cons 2
+ push_a 1
+ build e_StdGeneric_dGenericFieldDescriptor.gfd_name -4 e_StdGeneric_nGenericFieldDescriptor.gfd_name
+ fillh _Cons 2 6
+ pop_a 4
+.d 1 0
+ rtn
+.n 3 _ ea67
+.o 1 0
+n67
+ push_node _cycle_in_spine 3
+.o 4 0
+ea67
+.o 4 0
+s67
+ push_a 2
+ push_a 1
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.desc d9 _hnf l9 4 0 "gPrint_PAIR;10"
+.a 4 ea9
+.o 2 0
+l9
+ push_args 0 3 3
+ update_a 4 3
+ create
+ update_a 0 5
+ pop_a 1
+.o 5 0
+ea9
+ jsr_eval 2
+ jsr_eval 0
+.o 5 0
+s9
+ push_args 2 2 2
+ buildh _Nil 0
+ update_a 0 5
+ pop_a 1
+ push_a 5
+ push_a 2
+ push_a 5
+ build _ 3 n68
+ buildAC " "
+ buildh ARRAY 1
+ buildh _Cons 2
+ push_a 1
+ push_a 4
+ update_a 2 8
+ update_a 1 7
+ updatepop_a 0 6
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.n 3 _ ea68
+.o 1 0
+n68
+ push_node _cycle_in_spine 3
+.o 4 0
+ea68
+.o 4 0
+s68
+ push_a 2
+ push_a 1
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
+.o 3 0
+s39
+ push_a 1
+ push_a 1
+ buildh e_StdGeneric_dPAIR 2
+ fillh e_StdGeneric_dRECORD 1 3
+ pop_a 2
+.d 1 0
+ rtn
+.o 5 0
+s7
+ push_args 2 1 1
+ buildh _Nil 0
+ update_a 0 4
+ pop_a 1
+ push_a 4
+ buildAC "}"
+ buildh ARRAY 1
+ buildh _Cons 2
+ push_a 1
+ push_a 4
+ build _ 3 n69
+ buildAC "{"
+ buildh ARRAY 1
+ fillh _Cons 2 7
+ pop_a 5
+.d 1 0
+ rtn
+.n 3 _ ea69
+.o 1 0
+n69
+ push_node _cycle_in_spine 3
+.o 4 0
+ea69
+.o 4 0
+s69
+ push_a 2
+ push_a 1
+ jsr_eval 0
+ push_a 3
+ push_a 1
+ update_a 1 2
+ update_a 0 1
+ pop_a 1
+ update_a 2 5
+ update_a 1 4
+ updatepop_a 0 3
+ jsr_ap 2
+ fill_a 0 1
+ pop_a 1
+.d 1 0
+ rtn
--- /dev/null
+CLM?=clm
+CLMFLAGS?=-b
+
+BINARIES:=generic_eq generic_print
+
+all: $(BINARIES)
+
+%: %.icl
+ $(CLM) $(basename $<) $(OUTPUT_OPTION)
+
+clean:
+ $(RM) -r $(BINARIES) Clean\ System\ Files
--- /dev/null
+module Deep where
+
+import Prelude hiding (print)
+
+--data Value = I Int | B Bool
+-- deriving Show
+--data Expr
+-- = Lit Value
+-- | Plus Expr Expr
+-- | Eq Expr Expr
+-- deriving Show
+--
+--type Env = String -> Expr
+--
+--initialEnv :: Env
+--initialEnv _ = error "Unknown variable"
+--
+--addEnv :: String -> Expr -> Env -> Env
+--addEnv name expr env v
+-- | v == name = expr
+-- | otherwise = env v
+--
+--eval :: Env -> Expr -> Value
+--eval _ (Lit i) = Lit i
+--eval env (Plus l r) = case (eval env l, eval env r) of
+-- (Lit (I l), Lit (I r)) -> Lit (I (l+r))
+-- (l, r) -> error $ "Cannot add " ++ show l ++ " to " ++ show r
+--eval env (Eq l r) = case (eval env l, eval env r) of
+-- (Lit (I l), Lit (I r)) -> Lit (B (l==r))
+-- (Lit (B l), Lit (B r)) -> Lit (B (l==r))
+-- (l, r) -> error $ "Cannot compare " ++ show l ++ " to " ++ show r
+--
+--print :: Expr -> String
+--print (Lit i) = show i
+--print (Plus l r) = "(" ++ print l ++ "+" ++ print r ++ ")"
+--print (Eq l r) = "(" ++ print l ++ "==" ++ print r ++ ")"
+
+data Expr a where
+ Lit :: Show a => a -> Expr a
+ Plus :: Num a => Expr a -> Expr a -> Expr a
+ Eq :: Eq a => Expr a -> Expr a -> Expr Bool
+
+print :: Expr a -> String
+print (Lit i) = show i
+print (Plus l r) = "(" ++ print l ++ "+" ++ print r ++ ")"
+print (Eq l r) = "(" ++ print l ++ "==" ++ print r ++ ")"
+
+eval :: Expr a -> a
+eval (Lit i) = i
+eval (Plus l r) = eval l + eval r
+eval (Eq l r) = eval l == eval r
--- /dev/null
+module ExprGADT where
+import Prelude hiding (print)
+
+data Expr a where
+ Lit :: Show a => a -> Expr a
+ Add :: Num a => Expr a -> Expr a -> Expr a
+ Eq :: Eq e => Expr e -> Expr e -> Expr Bool
+
+eval :: Expr a -> a
+eval (Lit e) = e
+eval (Add l r) = eval l + eval r
+eval (Eq l r) = eval l == eval r
+
+print :: Expr a -> String
+print (Lit e) = show e
+print (Add l r) = print l ++ "+" ++ print r
+print (Eq l r) = print l ++ "==" ++ print r
--- /dev/null
+module expr_gadt
+import StdEnv
+
+:: BM a b = { ab :: a -> b, ba :: b -> a }
+bm :: BM a a
+bm = {ab=id, ba=id, tab=id, tba=id}
+
+:: Expr a
+ = E.e: Lit (BM a e) e & toString e
+ | E.e: Add (BM a e) (Expr e) (Expr e) & + e
+ | E.e: Eq (BM a Bool) (Expr e) (Expr e) & == e
+lit e = Lit bm e
+add l r = Add bm l r
+eq l r = Eq bm l r
+
+eval :: (Expr a) -> a
+eval (Lit bm e) = bm.ba e
+eval (Add bm l r) = bm.ba (eval l + eval r)
+eval (Eq bm l r) = bm.ba (eval l == eval r)
+
+print :: (Expr a) -> String
+print (Lit _ e) = toString e
+print (Add _ l r) = print l +++ "+" +++ print r
+print (Eq _ l r) = print l +++ "==" +++ print r
--- /dev/null
+module generic_eq
+import StdEnv, StdGeneric
+
+generic gEq a :: a a -> Bool
+
+gEq{|Int|} x y = x == y
+gEq{|Bool|} x y = x == y
+gEq{|Real|} x y = x == y
+gEq{|Char|} x y = x == y
+gEq{|UNIT|} x y = True
+gEq{|OBJECT|} f (OBJECT x) (OBJECT y) = f x y
+gEq{|CONS|} f (CONS x) (CONS y) = f x y
+gEq{|RECORD|} f (RECORD x) (RECORD y) = f x y
+gEq{|FIELD|} f (FIELD x) (FIELD y) = f x y
+gEq{|PAIR|} fl fr (PAIR lx rx) (PAIR ly ry) = fl lx ly && fr rx ry
+gEq{|EITHER|} fl _ (LEFT x) (LEFT y) = fl x y
+gEq{|EITHER|} _ fr (RIGHT x) (RIGHT y) = fr x y
+gEq{|EITHER|} _ _ _ _ = False
+
+:: T = C1 Int ([Char], ?Bool) | C2
+derive gEq [], T, (,), ?
+
+Start = (gEq{|*|} C2 (C1 42 ([], ?Just True)), gEq{|*->*|} (<) [1,2,3] [2,3,4])
+// (False, True)
--- /dev/null
+module generic_print
+import StdEnv, StdGeneric
+
+generic gPrint a :: a [String] -> [String]
+
+gPrint{|Int|} x acc = [toString x:acc]
+gPrint{|Bool|} x acc = [toString x:acc]
+gPrint{|Real|} x acc = [toString x:acc]
+gPrint{|Char|} x acc = [toString x:acc]
+gPrint{|UNIT|} x acc = acc
+gPrint{|OBJECT|} f (OBJECT x) acc = f x acc
+gPrint{|CONS of gcd|} f (CONS x) acc = ["(",gcd.gcd_name, " ":f x [")":acc]]
+gPrint{|RECORD of grd|} f (RECORD x) acc = ["{":f x ["}":acc]]
+gPrint{|FIELD of gfd|} f (FIELD x) acc = [gfd.gfd_name, "=":f x acc]
+gPrint{|PAIR|} fl fr (PAIR l r) acc = fl l [" ":fr r acc]
+gPrint{|EITHER|} fl _ (LEFT x) acc = fl x acc
+gPrint{|EITHER|} _ fr (RIGHT x) acc = fr x acc
+
+:: T = {f1 :: Int, f2 :: (Real, [?Int])}
+derive gPrint (,), [], ?, T
+
+Start = gPrint{|*|} {f1=42, f2=(3.14, [?None])} []
+// {f1=42 f2=(_Tuple2 3.14 (_Cons (_!None ) (_Nil )))}
\epigraph{%
The world is indeed comic, but the joke is on mankind.
}{%
- H.P.\ Lovecraft
+ Howard Philip Lovecraft
+}
+\epigraph{%
+ Рукописи не горят\\(Manuscripts don't burn)
+}{%
+ Михаил Афанасьевич Булгаков\\(Mikhail Afanesyevich Bulgakov)
+}
+\epigraph{%
+ You start a question, and it's like starting a stone.
+ You sit quietly on the top of a hill;
+ and away the stone goes, starting others;
+ \ldots
+}{%
+ Robert Louis Stevenson
+}
+\epigraph{%
+ I never thought, when I used to read books, what work it was to write them\ldots
+ It's work enough to read them sometimes\ldots
+ As to the writing, it has its own charms.
+}{%
+ Charles John Huffam Dickens
}
\vspace*{\fill}
+% Input encoding
+\usepackage[utf8]{inputenc}
+
% Papersize
\usepackage{geometry}
\geometry{
}
% Font encoding
-\usepackage[T1]{fontenc}
+\usepackage[T1,T2A]{fontenc}
% Less bad boxes
\usepackage{microtype}
% Internationalisation
\usepackage[british]{babel}
+%\babelfont[russian]{rm}{Liberation Serif}
% Appendices
% TODO is this necessary?
\usepackage[nodayofweek]{datetime}
% Code
+\usepackage{stmaryrd} % Short arrow
\usepackage{listings}
% General listings settings
\lstset{%
+ basewidth=0.43em,
+ basicstyle=\linespread{0.9}\tt\footnotesize,
breakatwhitespace=false,
breaklines=true,
captionpos=b,
+ columns=[c]fixed,
+ commentstyle=\sl,
+ escapeinside={(+}{+)}, % chktex 9
+ frame=L,
keepspaces=true,
- basicstyle=\ttfamily\fontseries{l}\footnotesize,
- commentstyle=\slshape\fontseries{m},
- keywordstyle=\bfseries\fontseries{b},
- stringstyle=\ttfamily,
+ keywordstyle=\bf,
+ postbreak=\mbox{\textcolor{gray}{$\hookrightarrow$}\space},
showspaces=false,
showstringspaces=false,
showtabs=false,
+ stringstyle=\it,
tabsize=4,
- frame=L,
+ literate=%
+ {~}{$\sim$}1
+ {\\}{{$\lambda\:$}}1
+ {->}{{$\shortrightarrow$}}2
+ {<-}{{$\shortleftarrow$}}2
+ {=>}{{$\Rightarrow$}}2
+ {<=}{{$\Leftarrow$}}2
+ {'}{{`}}1
+ {...}{{$\cdots$}}1 %chktex 11
+ {a0}{{a\textsubscript{0}}}2
+ {a1}{{a\textsubscript{1}}}2
+ {a2}{{a\textsubscript{2}}}2
+% {an}{{a\textsubscript{n}}}2
+ {c0}{{c\textsubscript{0}}}2
+ {c1}{{c\textsubscript{1}}}2
+ {c2}{{c\textsubscript{2}}}2
+ {cn}{{c\textsubscript{n}}}2
+ {f0}{{f\textsubscript{0}}}2
+ {f1}{{f\textsubscript{1}}}2
+ {f2}{{f\textsubscript{2}}}2
+ {fn}{{f\textsubscript{n}}}2
+ {t0}{{t\textsubscript{0}}}2
+ {t1}{{t\textsubscript{1}}}2
+ {t2}{{t\textsubscript{2}}}2
+ {tn}{{t\textsubscript{n}}}2
+ {v0}{{v\textsubscript{0}}}2
+ {v1}{{v\textsubscript{1}}}2
+ {v2}{{v\textsubscript{2}}}2
+ {vn}{{v\textsubscript{n}}}2
+ {C0}{{C\textsubscript{0}}}2
+ {C1}{{C\textsubscript{1}}}2
+ {C2}{{C\textsubscript{2}}}2
+ {Cn}{{C\textsubscript{n}}}2
+ {R0}{{R\textsubscript{0}}}2
+ {R1}{{R\textsubscript{1}}}2
+ {R2}{{R\textsubscript{2}}}2
+ {Rn}{{R\textsubscript{n}}}2
+}
+\lstdefinestyle{haskell}{%
+ language=Haskell,
+ deletekeywords={True,False,Bool,Int,Float,Double,zip,length,Show,show,Num,Eq,print,String},
+}
+\lstdefinelanguage{Clean}{%
+ alsoletter={ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_`1234567890},
+ alsoletter={~!@\#$\%^\&*-+=?<>:|\\.},
+ morekeywords={generic,implementation,definition,dynamic,module,import,from,where,in,of,case,let,infix,infixr,infixl,class,instance,with,if,derive,code,In,qualified,otherwise},
+ sensitive=true,
+ morecomment=[l]{//},
+ morecomment=[n]{/*}{*/},
+ morestring=[b]", % chktex 18
+ morestring=[s]{['}{']}, % chktex 9
}
+\newcommand{\cleaninline}[1]{\lstinline[language=Clean,postbreak=]|#1|}
+\newcommand{\haskellinline}[1]{\lstinline[language=Haskell,style=haskell,postbreak=]|#1|}
% Fix list of listings title
\renewcommand{\lstlistlistingname}{List of Listings}
% Fix list of listings chapter separator
\my@chapter}
\makeatother
+\lstnewenvironment{lstClean}[1][]
+ {%
+ \lstset{language=Clean, #1}
+ \renewcommand*{\lstlistingname}{Listing (Clean)}
+ }
+ {}
+\lstnewenvironment{lstHaskell}[1][]
+ {%
+ \lstset{language=Haskell,style=haskell,#1}%
+ \renewcommand*{\lstlistingname}{Listing (Haskell)}
+ }
+ {}
+
% Glossaries and acronyms
\usepackage[acronym,nonumberlist]{glossaries}
% Fix gls in hyperlink errors
\def\Acrfullpl#1{}%
\def\gls#1{}%
\def\glspl#1{}%
+ \def\glsentrytext#1{}%
\def\Gls#1{}%
\def\Glspl#1{}%
+ \def\Glsentrytext#1{}%
\def\titlecap#1{}%
}
\usepackage{fancyhdr}
\pagestyle{fancy}
+% Tables spanning pages
+\usepackage{longtable}
+
+% Easy references
+\usepackage{cleveref}
+
+% Diagrams
+\usepackage{tikz}
+\usetikzlibrary{pie}
+
% To patch the chapter command
\usepackage{etoolbox}
% Have better page numbering in chapters
% Initialize the glossaries
\makeglossaries%
\input{glossaries}
+
+% Custom commands
+\newcommand{\GHCmod}[1]{\texttt{#1}}
+\newcommand{\requiresGHCmod}[1]{\footnote{Requires \GHCmod{#1} to be enabled.}}
+\newcommand{\etc}{{\fontfamily{cmr}\selectfont{\itshape\/\&c}}}
-
@inproceedings{lubbers_multitasking_2019,
address = {Opatija, Croatia},
title = {Multitasking on {Microcontrollers} using {Task} {Oriented} {Programming}},
keywords = {domain specific languages, internet of things, network reliability, software architectures},
file = {Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:/home/mrl/.local/share/zotero/storage/YY3MJRZ6/Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:application/pdf}
}
+
+@misc{achten_clean_2007,
+ title = {Clean for {Haskell98} {Programmers}},
+ language = {en},
+ author = {Achten, Peter},
+ month = jul,
+ year = {2007},
+ file = {Achten - Clean for Haskell98 Programmers.pdf:/home/mrl/.local/share/zotero/storage/69WWSGLF/Achten - Clean for Haskell98 Programmers.pdf:application/pdf},
+}
+
+@article{groningen_exchanging_2010,
+ title = {Exchanging sources between {Clean} and {Haskell}: {A} double-edged front end for the {Clean} compiler},
+ volume = {45},
+ shorttitle = {Exchanging sources between {Clean} and {Haskell}},
+ number = {11},
+ journal = {ACM Sigplan Notices},
+ author = {Groningen, John van and Noort, Thomas van and Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
+ year = {2010},
+ pages = {49--60},
+ file = {groj10-Haskell_front_end_Clean.pdf:/home/mrl/.local/share/zotero/storage/WVZWX8WT/groj10-Haskell_front_end_Clean.pdf:application/pdf},
+}
+
+@techreport{plasmeijer_clean_2021,
+ address = {Nijmegen},
+ title = {Clean {Language} {Report} version 3.1},
+ urldate = {2021-12-22},
+ institution = {Institute for Computing and Information Sciences},
+ author = {Plasmeijer, Rinus and van Eekelen, Marko and van Groningen, John},
+ month = dec,
+ year = {2021},
+ pages = {127},
+ file = {CleanLanguageReport.pdf:/home/mrl/.local/share/zotero/storage/I2SDRIH6/CleanLanguageReport.pdf:application/pdf},
+}
+
+@inproceedings{brus_clean_1987,
+ address = {Berlin, Heidelberg},
+ title = {Clean — {A} language for functional graph rewriting},
+ isbn = {978-3-540-47879-9},
+ abstract = {Clean is an experimental language for specifying functional computations in terms of graph rewriting. It is based on an extension of Term Rewriting Systems (TRS) in which the terms are replaced by graphs. Such a Graph Rewriting System (GRS) consists of a, possibly cyclic, directed graph, called the data graph and graph rewrite rules which specify how this data graph may be rewritten. Clean is designed to provide a firm base for functional programming. In particular, Clean is suitable as an intermediate language between functional languages and (parallel) target machine architectures. A sequential implementation of Clean on a conventional machine is described and its performance is compared with other systems. The results show that Clean can be efficiently implemented.},
+ booktitle = {Functional {Programming} {Languages} and {Computer} {Architecture}},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Brus, T. H. and van Eekelen, M. C. J. D. and van Leer, M. O. and Plasmeijer, M. J.},
+ editor = {Kahn, Gilles},
+ year = {1987},
+ pages = {364--384},
+ file = {brut87-Clean.ps.gz:/home/mrl/.local/share/zotero/storage/T2QATWIE/brut87-Clean.ps.gz:application/gzip},
+}
+
+@inproceedings{barendregt_towards_1987,
+ title = {Towards an intermediate language for graph rewriting},
+ volume = {1},
+ booktitle = {{PARLE}, {Parallel} {Architectures} and {Languages} {Europe}},
+ publisher = {Springer Verlag},
+ author = {Barendregt, HP and van Eekelen, MCJD and Glauert, JRW and Kennaway, JR and Plasmeijer, MJ and Sleep, MR},
+ year = {1987},
+ pages = {159--174},
+ file = {barh87-Lean.ps.gz:/home/mrl/.local/share/zotero/storage/63FBHND7/barh87-Lean.ps.gz:application/gzip},
+}
+
+@inproceedings{nocker_concurrent_1991,
+ address = {Berlin, Heidelberg},
+ title = {Concurrent clean},
+ isbn = {978-3-540-47472-2},
+ abstract = {Concurrent Clean is an experimental, lazy, higher-order parallel functional programming language based on term graph rewriting. An important difference with other languages is that in Clean graphs are manipulated and not terms. This can be used by the programmer to control communication and sharing of computation. Cyclic structures can be defined. Concurrent Clean furthermore allows to control the (parallel) order of evaluation to make efficient evaluation possible. With help of sequential annotations the default lazy evaluation can be locally changed into eager evaluation. The language enables the definition of partially strict data structures which make a whole new class of algorithms feasible in a functional language. A powerful and fast strictness analyser is incorporated in the system. The quality of the code generated by the Clean compiler has been greatly improved such that it is one of the best code generators for a lazy functional language. Two very powerful parallel annotations enable the programmer to define concurrent functional programs with arbitrary process topologies. Concurrent Clean is set up in such a way that the efficiency achieved for the sequential case can largely be maintained for a parallel implementation on loosely coupled parallel machine architectures.},
+ booktitle = {{PARLE} '91 {Parallel} {Architectures} and {Languages} {Europe}},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Nöcker, E. G. J. M. H. and Smetsers, J. E. W. and van Eekelen, M. C. J. D. and Plasmeijer, M. J.},
+ editor = {Aarts, Emile H. L. and van Leeuwen, Jan and Rem, Martin},
+ year = {1991},
+ pages = {202--219},
+ file = {Nöcker et al. - 1991 - Concurrent clean.pdf:/home/mrl/.local/share/zotero/storage/XHTNR7BR/Nöcker et al. - 1991 - Concurrent clean.pdf:application/pdf},
+}
+
+@phdthesis{alimarine_generic_2005,
+ address = {Nijmegen},
+ type = {{PhD}},
+ title = {Generic {Functional} {Programming}},
+ language = {en},
+ school = {Radboud University},
+ author = {Alimarine, Artem},
+ year = {2005},
+ file = {Alimarine - Generic Functional Programming.pdf:/home/mrl/.local/share/zotero/storage/PDTS3SGX/Alimarine - Generic Functional Programming.pdf:application/pdf},
+}
+
+@misc{ghc_team_ghc_2021,
+ title = {{GHC} {User}’s {Guide} {Documentation}},
+ url = {https://downloads.haskell.org/~ghc/latest/docs/users_guide.pdf},
+ language = {English},
+ urldate = {2021-02-24},
+ publisher = {Release},
+ author = {GHC Team},
+ year = {2021},
+}
+
+@inproceedings{cheney_lightweight_2002,
+ title = {A lightweight implementation of generics and dynamics},
+ url = {http://dl.acm.org/citation.cfm?id=581698},
+ urldate = {2017-05-15},
+ booktitle = {Proceedings of the 2002 {ACM} {SIGPLAN} workshop on {Haskell}},
+ publisher = {ACM},
+ author = {Cheney, James and Hinze, Ralf},
+ year = {2002},
+ keywords = {dynamic typing, generic programming, type representations},
+ pages = {90--104},
+ file = {Cheney and Hinze - 2002 - A lightweight implementation of generics and dynam.pdf:/home/mrl/.local/share/zotero/storage/FZ6EGJRJ/Cheney and Hinze - 2002 - A lightweight implementation of generics and dynam.pdf:application/pdf;HW02.pdf:/home/mrl/.local/share/zotero/storage/A8Z49NK6/HW02.pdf:application/pdf},
+}
+
+@incollection{hinze_fun_2003,
+ address = {Palgrave},
+ series = {Cornerstones of {Computing}},
+ title = {Fun {With} {Phantom} {Types}},
+ isbn = {978-0-333-99285-2},
+ booktitle = {The {Fun} of {Programming}},
+ publisher = {Bloomsbury Publishing},
+ author = {Hinze, Ralf},
+ editor = {Gibbons, Jeremy and de Moor, Oege},
+ year = {2003},
+ pages = {245--262},
+}
+
+@inproceedings{jeuring_polytypic_1996,
+ address = {Berlin, Heidelberg},
+ title = {Polytypic programming},
+ isbn = {978-3-540-70639-7},
+ abstract = {Many functions have to be written over and over again for different datatypes, either because datatypes change during the development of programs, or because functions with similar functionality are needed on different datatypes. Examples of such functions are pretty printers, debuggers, equality functions, unifiers, pattern matchers, rewriting functions, etc. Such functions are called polytypic functions. A polytypic function is a function that is defined by induction on the structure of user-defined datatypes. This paper introduces polytypic functions, and shows how to construct and reason about polytypic functions. A larger example is studied in detail: polytypic functions for term rewriting and for determining whether a collection of rewrite rules is normalising.},
+ booktitle = {Advanced {Functional} {Programming}},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Jeuring, Johan and Jansson, Patrik},
+ editor = {Launchbury, John and Meijer, Erik and Sheard, Tim},
+ year = {1996},
+ pages = {68--114},
+ file = {Jeuring and Jansson - 1996 - Polytypic programming.pdf:/home/mrl/.local/share/zotero/storage/SLC4G2IT/Jeuring and Jansson - 1996 - Polytypic programming.pdf:application/pdf},
+}
+@techreport{cheney_first-class_2003,
+ title = {First-class phantom types},
+ url = {https://ecommons.cornell.edu/handle/1813/5614},
+ urldate = {2017-05-15},
+ institution = {Cornell University},
+ author = {Cheney, James and Hinze, Ralf},
+ year = {2003},
+ file = {https\://ecommons.cornell.edu/bitstream/handle/1813/5614/?sequence=1:/home/mrl/.local/share/zotero/storage/R5IFMHTP/5614.pdf:application/pdf}
+}
+@incollection{mernik_extensible_2013,
+ address = {Hershey, PA, USA},
+ title = {Extensible {Languages}: {Blurring} the {Distinction} between {DSL} and {GPL}},
+ isbn = {978-1-4666-2092-6},
+ url = {https://services.igi-global.com/resolvedoi/resolve.aspx?doi=10.4018/978-1-4666-2092-6.ch001},
+ abstract = {Out of a concern for focus and concision, domain-specific languages (DSLs) are usually very different from general purpose programming languages (GPLs), both at the syntactic and the semantic levels. One approach to DSL implementation is to write a full language infrastructure, including parser, interpreter, or even compiler. Another approach however, is to ground the DSL into an extensible GPL, giving you control over its own syntax and semantics. The DSL may then be designed merely as an extension to the original GPL, and its implementation may boil down to expressing only the differences with it. The task of DSL implementation is hence considerably eased. The purpose of this chapter is to provide a tour of the features that make a GPL extensible, and to demonstrate how, in this context, the distinction between DSL and GPL can blur, sometimes to the point of complete disappearance.},
+ booktitle = {Formal and {Practical} {Aspects} of {Domain}-{Specific} {Languages}: {Recent} {Developments}},
+ publisher = {IGI Global},
+ author = {Verna, Didier},
+ editor = {Mernik, Marjan},
+ year = {2013},
+ doi = {10.4018/978-1-4666-2092-6.ch001},
+ pages = {1--31},
+}
+
+@article{tratt_domain_2008,
+ title = {Domain {Specific} {Language} {Implementation} via {Compile}-{Time} {Meta}-{Programming}},
+ volume = {30},
+ issn = {0164-0925},
+ url = {https://doi.org/10.1145/1391956.1391958},
+ doi = {10.1145/1391956.1391958},
+ abstract = {Domain specific languages (DSLs) are mini-languages that are increasingly seen as being a valuable tool for software developers and non-developers alike. DSLs must currently be created in an ad-hoc fashion, often leading to high development costs and implementations of variable quality. In this article, I show how expressive DSLs can be hygienically embedded in the Converge programming language using its compile-time meta-programming facility, the concept of DSL blocks, and specialised error reporting techniques. By making use of pre-existing facilities, and following a simple methodology, DSL implementation costs can be significantly reduced whilst leading to higher quality DSL implementations.},
+ number = {6},
+ journal = {ACM Trans. Program. Lang. Syst.},
+ author = {Tratt, Laurence},
+ month = oct,
+ year = {2008},
+ note = {Place: New York, NY, USA
+Publisher: Association for Computing Machinery},
+ keywords = {compile-time meta-programming, domain specific languages, Syntax extension},
+ file = {Tratt - 2008 - Domain Specific Language Implementation via Compil.pdf:/home/mrl/.local/share/zotero/storage/HHGYJK4H/Tratt - 2008 - Domain Specific Language Implementation via Compil.pdf:application/pdf},
+}
+
+@inproceedings{sheard_accomplishments_2001,
+ address = {Berlin, Heidelberg},
+ title = {Accomplishments and {Research} {Challenges} in {Meta}-programming},
+ isbn = {978-3-540-44806-8},
+ abstract = {In the last ten years the study of meta-programming systems, as formal systems worthy of study in their own right, has vastly accelerated. In that time a lot has been accomplished, yet much remains to be done. In this invited talk I wish to review recent accomplishments and future research challenges in hopes that this will spur interest in meta-programming in general and lead to new and better meta-programming systems.},
+ booktitle = {Semantics, {Applications}, and {Implementation} of {Program} {Generation}},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Sheard, Tim},
+ editor = {Taha, Walid},
+ year = {2001},
+ pages = {2--44},
+ file = {Sheard - 2001 - Accomplishments and Research Challenges in Meta-pr.pdf:/home/mrl/.local/share/zotero/storage/M7NT6USA/Sheard - 2001 - Accomplishments and Research Challenges in Meta-pr.pdf:application/pdf},
+}
+
+@incollection{gibbons_functional_2015,
+ address = {Cham},
+ title = {Functional {Programming} for {Domain}-{Specific} {Languages}},
+ isbn = {978-3-319-15940-9},
+ url = {https://doi.org/10.1007/978-3-319-15940-9_1},
+ abstract = {Domain-specific languages are a popular application area for functional programming; and conversely, functional programming is a popular implementation vehicle for domain-specific languages—at least, for embedded ones. Why is this? The appeal of embedded domain-specific languages is greatly enhanced by the presence of convenient lightweight tools for defining, implementing, and optimising new languages; such tools represent one of functional programming's strengths. In these lectures we discuss functional programming techniques for embedded domain-specific languages; we focus especially on algebraic datatypes and higher-order functions, and their influence on deep and shallow embeddings.},
+ booktitle = {Central {European} {Functional} {Programming} {School}: 5th {Summer} {School}, {CEFP} 2013, {Cluj}-{Napoca}, {Romania}, {July} 8-20, 2013, {Revised} {Selected} {Papers}},
+ publisher = {Springer International Publishing},
+ author = {Gibbons, Jeremy},
+ editor = {Zsók, Viktória and Horváth, Zoltán and Csató, Lehel},
+ year = {2015},
+ doi = {10.1007/978-3-319-15940-9_1},
+ pages = {1--28},
+ file = {Gibbons - 2015 - Functional Programming for Domain-Specific Languag.pdf:/home/mrl/.local/share/zotero/storage/ARUBLFU6/Gibbons - 2015 - Functional Programming for Domain-Specific Languag.pdf:application/pdf},
+}
+
+@article{elliott_compiling_2003,
+ title = {Compiling embedded languages},
+ volume = {13},
+ doi = {10.1017/S0956796802004574},
+ number = {3},
+ journal = {Journal of Functional Programming},
+ author = {Elliott, Conal and Finne, Sigbjørn and de Moor, Oege},
+ year = {2003},
+ note = {Publisher: Cambridge University Press},
+ pages = {455--481},
+ file = {Elliott et al. - 2003 - Compiling embedded languages.pdf:/home/mrl/.local/share/zotero/storage/3X4Z6AKB/Elliott et al. - 2003 - Compiling embedded languages.pdf:application/pdf},
+}
+
+@book{fowler_domain-specific_2010,
+ title = {Domain-specific languages},
+ publisher = {Pearson Education},
+ author = {Fowler, Martin},
+ year = {2010},
+ file = {Fowler - 2010 - Domain-specific languages.pdf:/home/mrl/.local/share/zotero/storage/YYMYXTZ5/Fowler - 2010 - Domain-specific languages.pdf:application/pdf},
+}
+
+@inproceedings{hudak_modular_1998,
+ title = {Modular domain specific languages and tools},
+ doi = {10.1109/ICSR.1998.685738},
+ booktitle = {Proceedings. {Fifth} {International} {Conference} on {Software} {Reuse} ({Cat}. {No}.{98TB100203})},
+ author = {Hudak, P.},
+ year = {1998},
+ pages = {134--142},
+ file = {Hudak - 1998 - Modular domain specific languages and tools.pdf:/home/mrl/.local/share/zotero/storage/JX7KZ2ST/Hudak - 1998 - Modular domain specific languages and tools.pdf:application/pdf},
+}
+
+@inproceedings{baccelli_reprogramming_2018,
+ title = {Reprogramming {Low}-end {IoT} {Devices} from the {Cloud}},
+ booktitle = {2018 3rd {Cloudification} of the {Internet} of {Things} ({CIoT})},
+ publisher = {IEEE},
+ author = {Baccelli, Emmanuel and Doerr, Joerg and Jallouli, Ons and Kikuchi, Shinji and Morgenstern, Andreas and Padilla, Francisco Acosta and Schleiser, Kaspar and Thomas, Ian},
+ year = {2018},
+ pages = {1--6},
+ file = {Baccelli et al. - 2018 - Reprogramming Low-end IoT Devices from the Cloud.pdf:/home/mrl/.local/share/zotero/storage/M6LX5ZJN/Baccelli et al. - 2018 - Reprogramming Low-end IoT Devices from the Cloud.pdf:application/pdf},
+}
+
+@inproceedings{baccelli_scripting_2018,
+ title = {Scripting {Over}-{The}-{Air}: {Towards} {Containers} on {Low}-end {Devices} in the {Internet} of {Things}},
+ booktitle = {{IEEE} {PerCom} 2018},
+ author = {Baccelli, Emmanuel and Doerr, Joerg and Kikuchi, Shinji and Padilla, Francisco and Schleiser, Kaspar and Thomas, Ian},
+ year = {2018},
+ file = {Baccelli et al. - Scripting Over-The-Air Towards Containers on Low-.pdf:/home/mrl/.local/share/zotero/storage/98UTMFAC/Baccelli et al. - Scripting Over-The-Air Towards Containers on Low-.pdf:application/pdf},
+}
+
+@inproceedings{plasmeijer_task-oriented_2012,
+ address = {New York, NY, USA},
+ series = {{PPDP} '12},
+ title = {Task-{Oriented} {Programming} in a {Pure} {Functional} {Language}},
+ isbn = {978-1-4503-1522-7},
+ url = {https://doi.org/10.1145/2370776.2370801},
+ doi = {10.1145/2370776.2370801},
+ abstract = {Task-Oriented Programming (TOP) is a novel programming paradigm for the construction of distributed systems where users work together on the internet. When multiple users collaborate, they need to interact with each other frequently. TOP supports the definition of tasks that react to the progress made by others. With TOP, complex multi-user interactions can be programmed in a declarative style just by defining the tasks that have to be accomplished, thus eliminating the need to worry about the implementation detail that commonly frustrates the development of applications for this domain. TOP builds on four core concepts: tasks that represent computations or work to do which have an observable value that may change over time, data sharing enabling tasks to observe each other while the work is in progress, generic type driven generation of user interaction, and special combinators for sequential and parallel task composition. The semantics of these core concepts is defined in this paper. As an example we present the iTask3 framework, which embeds TOP in the functional programming language Clean.},
+ booktitle = {Proceedings of the 14th {Symposium} on {Principles} and {Practice} of {Declarative} {Programming}},
+ publisher = {Association for Computing Machinery},
+ author = {Plasmeijer, Rinus and Lijnse, Bas and Michels, Steffen and Achten, Peter and Koopman, Pieter},
+ year = {2012},
+ note = {event-place: Leuven, Belgium},
+ keywords = {clean, task-oriented programming},
+ pages = {195--206},
+ file = {103802.pdf:/home/mrl/.local/share/zotero/storage/ZE6A65AW/103802.pdf:application/pdf},
+}
+
+@incollection{wang_maintaining_2018,
+ address = {Cham},
+ title = {Maintaining {Separation} of {Concerns} {Through} {Task} {Oriented} {Software} {Development}},
+ volume = {10788},
+ isbn = {978-3-319-89718-9 978-3-319-89719-6},
+ url = {http://link.springer.com/10.1007/978-3-319-89719-6_2},
+ abstract = {Task Oriented Programming is a programming paradigm that enhances ‘classic’ functional programming with means to express the coordination of work among people and computer systems, the distribution and control of data sources, and the human-machine interfaces. To make the creation process of such applications feasible, it is important to have separation of concerns. In this paper we demonstrate how this is achieved within the Task Oriented Software Development process and illustrate the approach by means of a case study.},
+ language = {en},
+ urldate = {2019-01-14},
+ booktitle = {Trends in {Functional} {Programming}},
+ publisher = {Springer International Publishing},
+ author = {Stutterheim, Jurriën and Achten, Peter and Plasmeijer, Rinus},
+ editor = {Wang, Meng and Owens, Scott},
+ year = {2018},
+ doi = {10.1007/978-3-319-89719-6},
+ pages = {19--38},
+ file = {Stutterheim et al. - 2018 - Maintaining Separation of Concerns Through Task Or.pdf:/home/mrl/.local/share/zotero/storage/4GXJEM2U/Stutterheim et al. - 2018 - Maintaining Separation of Concerns Through Task Or.pdf:application/pdf},
+}
\documentclass[twoside,10pt]{book}
-
\def\mytitle{Big Things for Tiny Computers}
-\def\mysubtitle{Task Oriented Programming for the Internet of Things}
+\def\mysubtitle{Task-Oriented Programming for the Internet of Things}
\def\myauthor{Mart Lubbers}
+\def\mydate{\formatdate{1}{6}{2023}}
\input{preamble}
backgroundcolor=white,
linecolor=black,
size=scriptsize,
- inline,
}
% Document info
\title{\mytitle{} --- \mysubtitle{}}
\author{Mart Lubbers}
-\date{\formatdate{1}{6}{2023}}
+\date{\mydate}
\begin{document}
\frontmatter%
% The actual document
\mainmatter%
\addthumb{Chapters}{\arabic{chapter}}{white}{gray}
+\setcounter{chapter}{-1}
\chapter{Introduction}%
\label{chp:introduction}
\label{chp:appendix}
\addthumb{Appendices}{\Alph{chapter}}{white}{gray}
-\chapter{An Appendix}%
-\label{chp:an_appendix}
-\input{an_appendix}
+\chapter{\glsentrytext{CLEAN} for \glsentrytext{HASKELL} Programmers}%
+\label{chp:clean_for_haskell_programmers}
+\input{appendix/clean_for_haskell_programmers.tex}
\backmatter%
\addtitlethumb{Backmatter}{}{white}{gray}{pagesLTS.0}
\phantomsection{}%
\label{chp:bibliography}
\addcontentsline{toc}{chapter}{Bibliography}
-\bibliographystyle{plain}
+\bibliographystyle{alpha}
\bibliography{thesis}
% Abstract
\item[] Copromotor:
\begin{itemize}
\item[] dr.\ P.W.M.\ Koopman
+ \item[] dr.\ J.M.\ Jansen
\end{itemize}
\end{itemize}
\vfill
\noindent%
-\begin{minipage}[b][][b]{0.8\textwidth}% adapt widths of minipages to your needs
+\begin{minipage}[b][][b]{0.8\textwidth} % adapt widths of minipages to your needs
{
\setlength{\parindent}{0cm}%
This research was funded by the Royal Netherlands Navy.
repositories / phd-thesis.git / commitdiff