\begin{document}
\input{subfileprefix}
\ifSubfilesClassLoaded{\appendix}{}
-\chapter{\texorpdfstring{\glsentrytext{CLEAN}}{Clean} for \texorpdfstring{\glsentrytext{HASKELL}}{Haskell} programmers}%
+\chapter{Clean for Haskell programmers}%
\label{chp:clean_for_haskell_programmers}
-This appendix is meant give people who are familiar with the \gls{FP} language \gls{HASKELL} a consise overview of the programming language \gls{CLEAN} and how it differs from \gls{HASKELL}.
+This appendix is meant give people who are familiar with the \gls{FP} language \gls{HASKELL} a concise overview of the programming language \gls{CLEAN} and how it differs from \gls{HASKELL}.
The goal is to support the reader when reading \gls{CLEAN} code.
-\Cref{tbl:syn_clean_haskell} shows frequently occuring \gls{CLEAN} language elements on the left side and their \gls{HASKELL} equivalent on the right side.
+\Cref{tbl:syn_clean_haskell} shows frequently occurring \gls{CLEAN} language elements on the left side and their \gls{HASKELL} equivalent on the right side.
Obviously, this summary is not exhaustive.
Some \gls{CLEAN} language elements that are not easily translatable to \gls{HASKELL} and thus do not occur in the summary following below.
We hope you enjoy these notes and that it aids you in reading \gls{CLEAN} programs.
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 \citep{van_groningen_exchanging_2010}, however this frontend is no longer maintained.
+In the past, a \emph{double-edged} fronted even existed that allowed \gls{CLEAN} to be extended with \gls{HASKELL}98 syntax and vice versa \citep{van_groningen_exchanging_2010}, however this frontend is no longer maintained.
This chapter gives only a brief syntactical and functional comparison.
A complete specification of the \gls{CLEAN} language can be found in the latest language report \citep{plasmeijer_clean_2021}.
-Much of this is based on work by Achten, although that was based on \gls{CLEAN} 2.1 and \gls{HASKELL98} \citep{achten_clean_2007}.
+Much of this is based on work by Achten, although that was based on \gls{CLEAN} 2.1 and \gls{HASKELL}98 \citep{achten_clean_2007}.
When \gls{HASKELL} is mentioned we actually mean \gls{GHC}'s \gls{HASKELL}\footnote{If an extension is enabled, a footnote is added stating that \GHCmod{SomeExtension} is required.} and by \gls{CLEAN} we mean \gls{CLEAN} 3.1's compiler with the \gls{ITASK} extensions.
\section{Features}
Within functions, the strict let (\cleaninline{#!}) is 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 cannot be shared \citep{barendsen_uniqueness_1996}.
+Types in \gls{CLEAN} may be \emph{unique}, which means that instances of the type cannot be shared \citep{barendsen_uniqueness_1996}.
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 \citep{achten_high_1993,achten_ins_1995}.
\Gls{CLEAN} uses the \emph{world-as-value} paradigm where \cleaninline{World} represents the external environment and is always unique \citep{backus_introduction_1990}.
\end{lstClean}
\subsection{Generics}
-Polytypic functions \citep{jeuring_polytypic_1996}---also known as generic or kind-indexed fuctions---are built into \gls{CLEAN} \citep[\citesection{7.1}]{plasmeijer_clean_2021}\citep{alimarine_generic_2005} whereas in \gls{HASKELL} they are implemented as a library \citep[\citesection{6.19.1}]{ghc_team_ghc_2021}.
+Polytypic functions \citep{jeuring_polytypic_1996}---also known as generic or kind-indexed functions---are built into \gls{CLEAN} \citep[\citesection{7.1}]{plasmeijer_clean_2021}\citep{alimarine_generic_2005} whereas in \gls{HASKELL} they are implemented as a library \citep[\citesection{6.19.1}]{ghc_team_ghc_2021}.
The syntax of the built-in generics of \gls{CLEAN} is very similar to that of Generic H$\forall$skell \citep{hinze_generic_2003}.
%When calling a generic function, the kind must always be specified and depending on the kind, the function may require more arguments.
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 (see \cref{chp:first-class_datatypes,sec:ccodegen}).
\cleaninputlisting[language=Clean,firstline=4,label={lst:generic_print},caption={Generic print function}]{lst/generic_print.icl}
-\subsection{\texorpdfstring{\glsentrytext{GADT}}{GADT}s}
+\subsection{GADTs}
\Glspl{GADT} are enriched data types that allow the type instantiation of the constructor to be explicitly defined \citep{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 \citep[\citesection{2.2}]{cheney_lightweight_2002}.
To illustrate this, \cref{lst:gadt_haskell} shows a \gls{GADT} in \gls{HASKELL}\requiresGHCmod{GADTs} that can be implemented as in \cref{lst:gadt_clean}.
\clearpage
\section{Syntax}
\lstset{basicstyle=\tt\footnotesize}
-\begin{longtable}{p{.45\linewidth}p{.5\linewidth}}
+\begin{longtable}{p{.46\linewidth}p{.46\linewidth}}
\caption[]{Syntactical differences between \gls{CLEAN} and \gls{HASKELL}.}%
\label{tbl:syn_clean_haskell}\\
\toprule
\gls{CLEAN} & \gls{HASKELL}\\
\midrule
\endfirsthead%
- \caption[]{(continued)}\\
+ \caption[]{Syntactical differences between \gls{CLEAN} and \gls{HASKELL}. (continued)}\\
\toprule
\gls{CLEAN} & \gls{HASKELL}\\
\midrule