\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 Arduino\cite{koopman_type-safe_nodate}%
+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
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 of kind \CI{*->*->*} that
-implements some of the classes given. The types do not have to be present as
-fields in the higher kinded view and can, and will most often, solely be
-phantom types. A view is of the form \CI{v t r}. The first 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 a \CI{Upd} and a \CI{Expr} are
-expressions. The \CI{Upd} restriction describes updatable expressions such as
-\gls{GPIO} pins and \gls{SDS}.
+A view for the \gls{mTask}-\gls{EDSL} is a type with kind \CI{*->*->*}%
+\footnote{A type with two free type variables.} that implements some of the
+classes given. The types do not have to be present as fields in the higher
+kinded view and can, and will most often, solely be phantom types. A view is 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 a \CI{Upd} and a \CI{Expr} are expressions. The \CI{Upd}
+restriction describes updatable expressions such as \gls{GPIO} pins and
+\glspl{SDS}.
\begin{lstlisting}[%
language=Clean,label={lst:exprhier},caption={Expression role hierarchy}]
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 is the
-sequence operator and the \emph{if} statement. Both are shown in
-Listing~\ref{lst:control}. The first class of \emph{If} statements describe 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 sequence operator is very straightforward and just ties the two expressions
-together in sequence.
+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.
+
+The sequence operator is very straightforward and just ties
+the two expressions together in sequence.
\begin{lstlisting}[%
language=Clean,label={lst:control},caption={Control flow operators}]
class If v q r ~s where
If :: (v Bool p) (v t q) (v t r) -> v t s | ...
+instance If Code Stmt Stmt Stmt
+instance If Code e Stmt Stmt
+instance If Code Stmt e Stmt
+instance If Code x y Expr
+
class seq v where
(:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
\end{lstlisting}
\section{Input/Output and class extensions}
-All expressions that have an \CI{Upd} role can be assigned to. Examples of such
-expressions are \glspl{SDS} and \gls{GPIO}. Moreover, class extensions can be
-created for specific peripherals such as user LEDs. The classes facilitating
-this are shown in Listing~\ref{lst:sdsio}. In this way the assignment is the
-same for every assignable entity.
+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 builtin \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.
\begin{lstlisting}[%
language=Clean,label={lst:sdsio},caption={Input/Output classes}]
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.
The classes associated with \glspl{SDS} are listed in
-Listing~\ref{lst:sdsclass}. The \CI{Main} class is introduced to box an
+Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an
\gls{mTask} and make it recognizable by the type system.
\begin{lstlisting}[%
The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
semantics. This engine expressed in pseudocode is listed as
Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
-time. When the waiting time has not passed the delta is subtracted and they are
-pushed to the end of the queue. When the waiting has has surpassed they are
-executed. When a \gls{mTask} wants to queue another \gls{mTask} it can just
+time. When the waiting time has not passed; the delta is subtracted and the
+task gets pushed to the end of the queue. When the waiting has surpassed they are
+executed. When an \gls{mTask} wants to queue another \gls{mTask} it can just
append it to the queue.
\begin{algorithm}[H]
similar fashion as the \texttt{sds} class. This class is listed in
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
-rather arcane and therefore an example is given. The aforementioned Listing
+complex and therefore an example is given. The aforementioned Listing
shows a simple specification containing one task that increments a value
indefinitely every one seconds.
Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
to a particular view and therefore are of the type \CI{View t r}. The
\CI{blink} \gls{mTask} show the classic \gls{Arduino} \emph{Hello World!}
-application that blinks a certain 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.
+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.
\begin{lstlisting}[%
language=Clean,label={lst:exmtask},caption={Some example \glspl{mTask}}]
repositories / msc-thesis1617.git / blobdiff