\documentclass[../thesis.tex]{subfiles}

\begin{document}
\ifSubfilesClassLoaded{
	\pagenumbering{arabic}
}{}

\chapter{\Gls{TOP} for the \gls{IOT}}
\begin{chapterabstract}
	This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microprocessor programming.
\end{chapterabstract}
Traditionally, the first program that one writes when trying a new language is the so called \emph{Hello World!} program.
This program has the single task of printing the text \emph{Hello World!} to the screen and exiting again, useful to become familiarised with the syntax and verify that the toolchain and runtime environment is working.
On microprocessors, there often is no screen for displaying text.
Nevertheless, almost always there is a monochrome $1\times1$ pixel screen, namely an---often builtin---\gls{LED}.
The \emph{Hello World!} equivalent on microprocessors blinks this \gls{LED}.

\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{CPP} dialect.
Every \gls{ARDUINO} program contains a \arduinoinline{setup} and a \arduinoinline{loop} function.
The \arduinoinline{setup} function is executed only once on boot, the \arduinoinline{loop} function is continuously called afterwards and contains the event loop.
After setting the \gls{GPIO} pin to the correct mode, blink's \arduinoinline{loop} function alternates the state of the pin representing the \gls{LED} between \arduinoinline{HIGH} and \arduinoinline{LOW}, turning the \gls{LED} off and on respectively.
In between it waits for 500 milliseconds so that the blinking is actually visible for the human eye.
Compiling this results in a binary firmware that needs to be flashed onto the program memory.

Translating the traditional blink program to \gls{MTASK} can almost be done by simply substituting some syntax as seen in \cref{lst:blinkImp}.
E.g.\ \cleaninline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit} and the pin to blink is changed to represent the actual pin for the builtin \gls{LED} of the device used in the exercises.
In contrast to the imperative \gls{CPP} dialect, \gls{MTASK} is a \gls{TOP} language and therefore there is no such thing as a loop, only task combinators to combine tasks.
To simulate a loop, the \cleaninline{rpeat} task can be used, this task executes the argument task and, when stable, reinstates it.
The body of the \cleaninline{rpeat} contains similarly named tasks to write to the pins and to wait in between.
The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.

\begin{figure}[!ht]
	\begin{subfigure}[b]{.5\linewidth}
		\begin{lstArduino}[caption={Blink program.},label={lst:arduinoBlink}]
void setup() {
	pinMode(D2, OUTPUT);
}

void loop() {
	digitalWrite(D2, HIGH);
	delay(500);
	digitalWrite(D2, LOW);
	delay(500);
}\end{lstArduino}
	\end{subfigure}%
	\begin{subfigure}[b]{.5\linewidth}
		\begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]

blink :: Main (MTask v ()) | mtask v
blink =
	declarePin D4 PMOutput \d4->
	{main = rpeat (
		     writeD d4 true
		>>|. delay (lit 500)
		>>|. writeD d4 false
		>>|. delay (lit 500)
	)}\end{lstClean}
	\end{subfigure}
\end{figure}

\chapter{The \gls{MTASK} \gls{DSL}}
\begin{chapterabstract}
This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
\end{chapterabstract}

The \gls{MTASK} system is a \gls{TOP} programming environment for programming microprocessors.
It is implemented as an \gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (See~\cref{ssec:tagless}).
Due to the nature of the embedding technique, it is possible to have multiple interpretations of---or views on---programs written in the \gls{MTASK} language.

\begin{itemize}
	\item Pretty printer

		This interpretation converts the expression to a string representation.
	\item Simulator

		The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.
	\item Compiler

		The compiler compiles the \gls{MTASK} program at runtime to a specialised bytecode.
		Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microprocessors and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
		Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.
\end{itemize}

\section{Types}
To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
However, not all types in the host language are suitable for microprocessors that may only have 2KiB of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints etc.
Many of these functions can be derived using generic programming.
An even stronger restriction on types is defined for types that have a stack representation.
This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
The class constraints for values in \gls{MTASK} are omnipresent in all functions and therefore often omitted throughout throughout the chapters for brevity and clarity.

\begin{table}[ht]
	\centering
	\begin{tabular}{lll}
		\toprule
		\gls{CLEAN}/\gls{MTASK} & \gls{CPP} type & \textnumero{}bits\\
		\midrule
		\cleaninline{Bool}             & \cinline{bool}    & 16\\
		\cleaninline{Char}             & \cinline{char}    & 16\\
		\cleaninline{Int}              & \cinline{int16_t} & 16\\
		\cleaninline{:: Long}          & \cinline{int32_t} & 32\\
		\cleaninline{Real}             & \cinline{float}   & 32\\
		\cleaninline{:: T = A | B | C} & \cinline{enum}    & 16\\
		\bottomrule
	\end{tabular}
	\caption{Mapping from \gls{CLEAN}/\gls{MTASK} data types to \gls{CPP} datatypes.}%
	\label{tbl:mtask-c-datatypes}
\end{table}

The \gls{MTASK} language consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}.
Every interpretation implements the type classes in the \cleaninline{mtask} class
There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and integration with \gls{ITASK}.

\Cref{lst:constraints} contains the definitions for the type constraints and shows some example type signatures for typical \gls{MTASK} expressions and tasks.

\begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
class type t | iTask, ... ,fromByteCode, toByteCode t
class basicType t | type t where ...

class mtask v | expr, ..., int, real, long v

someExpr :: v Int | mtask v
tempTask :: MTask v Bool | mtask, dht v
\end{lstClean}

\section{Expressions}
\Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}), to do basic arithmetics and conditional execution.
For every common arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.

\begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}]
class expr v where
	lit :: t -> v t | type t
	(+.) infixl 6 :: (v t) (v t) -> v t | basicType, +, zero t
	(-.) infixl 6 :: (v t) (v t) -> v t | basicType, -, zero t
	(*.) infixl 7 :: (v t) (v t) -> v t | basicType, *, zero, one t
	(/.) infixl 7 :: (v t) (v t) -> v t | basicType, /, zero t
	(&.) infixr 3 :: (v Bool) (v Bool) -> v Bool
	(|.) infixr 2 :: (v Bool) (v Bool) -> v Bool
	Not           :: (v Bool) -> v Bool
	(==.) infix 4 :: (v a) (v a) -> v Bool | Eq, basicType a
	(!=.) infix 4 :: (v a) (v a) -> v Bool | Eq, basicType a
	(<.)  infix 4 :: (v a) (v a) -> v Bool | Ord, basicType a
	(>.)  infix 4 :: (v a) (v a) -> v Bool | Ord, basicType a
	(<=.) infix 4 :: (v a) (v a) -> v Bool | Ord, basicType a
	(>=.) infix 4 :: (v a) (v a) -> v Bool | Ord, basicType a
	If :: (v Bool) (v t) (v t) -> v t | type t
\end{lstClean}

Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}.

\begin{lstClean}
class int  v a :: (v a) -> v Int
class real v a :: (v a) -> v Real
class long v a :: (v a) -> v Long
\end{lstClean}

Finally, values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.
For convenience, there are many lower-cased macro definitions for often used constants as can be seen in \cref{lst:convenience_lits}

\begin{lstClean}[label={lst:convenience_lits}]
// Booleans
true  :== lit True
false :== lit False
\end{lstClean}

\subsection{Functions}

\section{Tasks}
\subsection{Basic tasks}
\subsubsection{Peripherals}
\subsection{Task combinators}
\subsubsection{Parallel}
\subsubsection{Sequential}
\subsubsection{Miscellaneous}
\subsection{\glspl{SDS}}

\chapter{Green computing with \gls{MTASK}}

\chapter{Integration with \gls{ITASK}}
\section{Devices}
\section{Lift tasks}
\section{Lift \glspl{SDS}}

\chapter{Implementation}
IFL19 paper, bytecode instructieset~\cref{chp:bytecode_instruction_set}

\section{Integration with \gls{ITASK}}
IFL18 paper stukken

\input{subfilepostamble}
\end{document}
