-The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The
-\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support 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 system for
-microcontrollers such as the \gls{Arduino}\cite{koopman_type-safe_nodate}%
+The \gls{mTask}-\gls{EDSL} is the language used in the system. The
+\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supported 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
host-language value into the \gls{EDSL} domain. All standard arithmetic
functions are included in the \gls{EDSL} but are omitted in the example for
brevity. Moreover, the class restrictions are only shown in the first functions
-and omitted in subsequent funcitons. Both the boolean expression and arithmetic
+and omitted in subsequent functions. Both the boolean expression and arithmetic
expression classes are shown in Listing~\ref{lst:arithbool}.
\begin{lstlisting}[label={lst:arithbool},
\section{Control flow}
Looping of \glspl{Task} happens because \glspl{Task} are executed after waiting
-a specified amount of time or when they are launched by another task or even
-themselves. Therefore there is no need for loop control flow functionality such
-as \emph{while} or \emph{for} constructions. The main control flow operators
-are the sequence operator and the \emph{if} statement. Both are shown in
-Listing~\ref{lst:control}. The first class of \emph{If} statements describes
+a specified amount of time or when they are launched by another \gls{Task} or
+even themselves. Therefore there is no need for loop control flow functionality
+such as \emph{while} or \emph{for} constructions. The main control flow
+operators are the sequence operator and the \emph{if} statement. Both are shown
+in Listing~\ref{lst:control}. The first class of \emph{If} statements describes
the regular \emph{if} statement. The expressions given can have any role. The
-functional dependency on \CI{s} determines the return type of the
-statement. The listing includes examples of implementations that illustrate
-this dependency.
+functional dependency on \CI{s} determines the return type of the statement.
+The listing includes examples of implementations that illustrate this
+dependency.
The sequence operator is very straightforward and its only function is to tie
the together in sequence.
Values can be assigned to all expressions that have an \CI{Upd} role. Examples
of such expressions are \glspl{SDS} and \gls{GPIO} pins. Moreover, class
extensions can be created for specific peripherals such as built-in
-\glspl{LED}. The classes facilitating this are shown in
+\glspl{LED}. The classes facilitating this are shown in
Listing~\ref{lst:sdsio}. In this way the assignment is the same for every
assignable entity.
\end{lstlisting}
A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
-as variables in the \gls{mTask} and maintain their value across executions.
+as variables in \gls{mTask} and maintain their value across executions.
+\glspl{SDS} can be used by multiple \glspl{Task} and can be used to share data.
The classes associated with \glspl{SDS} are listed in
Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an
-\gls{mTask} and make it recognizable by the type system.
+\gls{mTask} and make it recognizable by the type system by separating programs
+and decorations such as \glspl{SDS}.
\begin{lstlisting}[%
label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}]
Listing~\ref{lst:taskclass}. \glspl{Task} can have an argument and always have
to specify a delay or waiting time. The type signature of the \CI{mtask} is
complex and therefore an example is given. The aforementioned Listing
-shows a simple specification containing one task that increments a value
+shows a simple specification containing one \gls{Task} that increments a value
indefinitely every one seconds.
\begin{lstlisting}[label={lst:taskclass},%
- caption={The classes for defining tasks}]
+ caption={The classes for defining \glspl{Task}}]
class mtask v a where
task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ...
application that blinks a certain \gls{LED} every second. The \CI{thermostat}
expression will enable a digital pin powering a cooling fan when the analog pin
representing a temperature sensor is too high. \CI{thermostat`} shows the same
-expression but now using the assignment style \gls{GPIO} technique.
+expression but now using the assignment style \gls{GPIO} technique. The
+\CI{thermostat} example also show that it is not necessary to run everything as
+a \CI{task}. The main program code can also just consist of the contents of the
+root \CI{main} itself.
\begin{lstlisting}[%
label={lst:exmtask},caption={Some example \glspl{mTask}}]
repositories / msc-thesis1617.git / blobdiff