The \gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supports several
views such as an \gls{iTasks} simulation and a \gls{C}-code generator. The
\gls{EDSL} was designed to generate a ready-to-compile \gls{TOP}-like program
for microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%
\cite{plasmeijer_shallow_2016}.

The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
therefore it is very suitable to have a new backend that partly implements the
classes given. The following sections show the details of the \gls{EDSL} that
is used in this extension. The parts of the \gls{EDSL} that are not used will
not be discussed and the details of those parts can be found in the cited
literature.

A view for the \gls{mTask}-\gls{EDSL} is a type with two free type
variables\footnote{kind \CI{*->*->*}.} that implements some of the classes
given. The types do not have to be present as fields in the view and can, and
will most often, be exclusively phantom types. Thus, views are of the
form:\\\CI{:: v t r = ...}. The first type variable will be the type of the
view. The second type variable will be the type of the \gls{EDSL}-expression
and the third type variable represents the role of the expression. Currently
the role of the expressions form a hierarchy. The three roles and their
hierarchy are shown in Listing~\ref{lst:exprhier}. This implies that everything
is a statement, only an \CI{Upd} and an \CI{Expr} are expressions. The \CI{Upd}
restriction describes updatable expressions such as \gls{GPIO} pins and
\glspl{SDS}.

\begin{lstlisting}[%
	label={lst:exprhier},caption={Expression role hierarchy}]
:: Upd   = Upd
:: Expr  = Expr
:: Stmt  = Stmt

class isExpr a :: a -> Int
instance isExpr Upd
instance isExpr Expr
\end{lstlisting}

\section{Expressions}
\input{mtask.expr}

\section{Control flow}
\input{mtask.control}

\section{Input/Output and Class Extensions}
\input{mtask.io}

\section{Semantics}
\input{mtask.semantics}

\section{Example mTask}
\input{mtask.examples}
