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
+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}.
+\glspl{SDS}. The roles are used to constrain certain classes. For example,
+without the roles for \CI{Upd}. Assignment would be possible to a
+non-assignable expression such as a literal integer.
-\begin{lstlisting}[%
+\begin{lstlisting}[language=Clean,%
label={lst:exprhier},caption={Expression role hierarchy}]
:: Upd = Upd
:: Expr = Expr
\section{Control flow}
\input{mtask.control}
-\section{Input/Output and Class Extensions}
+\section{Input/Output}
\input{mtask.io}
-\section{Semantics}
-\input{mtask.semantics}
+\section{Class Extensions}
+\input{mtask.class}
+
+\section{Scheduling Strategy}
+\input{mtask.scheduling}
\section{Example mTask}
\input{mtask.examples}