-This thesis presents a way to connect small \gls{IoT} devices with high level
-\gls{TOP} implementations languages. It shows how a new frontend for the class
-based shallowly \gls{EDSL} called \gls{mTask} written in \gls{Clean}
-can be used to compile \gls{IoT}-tasks on the fly and send them to devices
-as interpretable bytecode. All of this adheres to the \gls{TOP} philosophy
-where familiar concepts such as \glspl{SDS} and task-combinators are available
-at ease.
+This thesis introduces a way to connect small \gls{IoT} devices with high level
+\gls{TOP} implementations languages. It demonstrates how a new frontend for the
+class-based shallowly \gls{EDSL} called \gls{mTask} written in \gls{Clean} can
+be employed to compile \gls{IoT}-tasks on the fly and send them to devices as
+interpretable bytecode. All of which adheres to the \gls{TOP} philosophy where
+common concepts such as \glspl{SDS} and task-combinators are available at ease.
-I would like to thank everyone that helped me writing thesis. This includes but
+I would like to thank everyone who helped me writing thesis. This includes but
is not limited to Rinus and Pieter for the support, supervision and weekly
sparring. Bas for providing the needed \gls{iTasks} support. Arjan for the
sparring and coffee. George, Camil and others\todo{proofreaders}\ for
description={is a cheap and popular microcontroller that is widely used for
rapid prototyping}}
\newglossaryentry{Clean}{name={\emph{Clean}},
- description={is a staticly typed pure lazy functional programming language based on graph
- rewriting}}
+ description={is a statically typed pure lazy functional programming
+ language based on graph rewriting}}
\newglossaryentry{Haskell}{name={\emph{Haskell}},
description={is a staticly typed pure lazy functional programming language}}
\newglossaryentry{iTasks}{name=\emph{iTasks},
- description={is a \acrshort{TOP} implementation written as a \acrshort{EDSL}
- in the \gls{Clean} programming language}}
+ description={is a \acrshort{TOP} implementation written as an
+ \acrshort{EDSL} in the \gls{Clean} programming language}}
\newglossaryentry{Ivory}{name={\emph{Ivory}},
description={is a type-safe \gls{EDSL} designed to generate \gls{C}-code
for high-assurance low-level systems}}
\gls{GPS} or the Russian \gls{GLONASS}} and actuators%
\cite{da_xu_internet_2014}. With these new technologies information
can be tracked very accurately using very little power and bandwidth. Moreover,
-\gls{IoT} technology is coming into people's homes, clothes and in
+\gls{IoT} technology is coming into people's homes, clothes and
healthcare\cite{riazul_islam_internet_2015}. For example, for a few euros a
consumer ready fitness tracker watch can be bought that tracks heartbeat and
respiration levels.
generated for the types of data which makes rapid development possible.
\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
tasks but the modelling is applied on a very high level. Therefore it is
-difficult to connect \gls{iTasks}-\glspl{Task} to real world tasks and let
-them interact. A lot of the actual tasks could be performed by small
+difficult to connect \gls{iTasks}-\glspl{Task} to real world \glspl{Task} and
+allow them to interact. A lot of the actual tasks could be performed by small
\gls{IoT} devices. Nevertheless, adding such devices to the current system is
difficult to say the least as it was not designed to cope with these devices.
such as time are available in the current \gls{iTasks} implementation}.
However, this
requires a very specific adapter to be written for every device and function.
-This forces a fixed logic in the device that is set at compile time. A
-lot of the small \gls{IoT} devices have limited processing power but can still
-contain decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single
-server model to a distributed server architecture that is also runnable on
-smaller devices like \acrshort{ARM} devices\cite{oortgiese_distributed_2017}.
-However, this is limited to fairly high performance devices that are equipped
-with high speed communication channels. Devices in \gls{IoT} often have only
-\gls{LTN} communication with low bandwidth and a very limited amount of
-processing power and are therefore not suitable to run an entire \gls{iTasks}
-core.
+This forces a fixed logic in the device that is set at compile time. Many
+small \gls{IoT} devices have limited processing power but can still contain
+decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single server
+model to a distributed server architecture that is also runnable on small
+devices such as those powered by \acrshort{ARM}~\cite{%
+oortgiese_distributed_2017}. However, this is limited to fairly high
+performance devices that are equipped with high speed communication channels.
+Devices in \gls{IoT} often have only \gls{LTN} communication with low bandwidth
+and a very limited amount of processing power and are therefore not suitable to
+run an entire \gls{iTasks} core.
\section{Problem statement}
The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
methods to create \gls{EDSL}.
Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
-extended on in this dissertation.
+extended upon in this dissertation.
Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
are a part of the new \gls{mTask}-system.
Chapter~\ref{chp:mtaskcont} shows the extension added to the
| And DSL DSL
| Eq DSL
\end{lstlisting}
+
Deep embedding has the advantage that it is very simple to build and the views
are easy to add. To the downside, the expressions created with this language
are not type-safe. In the given language it is possible to create an expression
-such as \CI{Plus (LitI 4) (LitB True)} that adds a a boolean to an integer.
+such as \CI{Plus (LitI 4) (LitB True)} that adds a boolean to an integer.
Evermore so, extending the \gls{ADT} is easy and convenient but extending the
views accordingly is tedious and has to be done individually for all views.
The advantage of shallowly embedding a language in a host language is its
extendability. It is very easy to add functionality and compile time checks
-of the host language guarantee whether the functionality is available when used.
-Moreover, the language is type safe as it is directly typed in the host
-language.
+of the host language guarantee whether or not the functionality is available
+when used. Moreover, the language is type safe as it is directly typed in the
+host language.
The downside of this method is extending the language with views. It is nearly
impossible to add views to a shallowly embedded language. The only way of
implement.
\section{Class based shallow embedding}
-The third type of embedding is called class based shallow embedding and has the
-advantages of both shallow and deep embedding. In class based shallow embedding
-the language constructs are defined as type classes. The same language is shown
+The third type of embedding is called class-based shallow embedding and has the
+advantages of both shallow and deep embedding. In class-based shallow embedding
+the language constructs are defined as type classes. This language is shown
with the new method in Listing~\ref{lst:exclassshallow}.
This type of embedding inherits the easiness of adding views from shallow
type classes as shown in the aforementioned Listing where an evaluator and a
pretty printer are implemented.
-Just as with \glspl{GADT} in deep embedding type safety is guaranteed. Type
+Just as with \glspl{GADT}, type safety is guaranteed in deep embedding. Type
constraints are enforced through phantom types. One can add as many phantom
-type as necessary. Lastly, extensions can be added easily, just as in
+types as necessary. Lastly, extensions can be added easily, just as in
shallow embedding. When an extension is made in an existing class, all views
must be updated accordingly to prevent possible runtime errors. When an
extension is added in a new class, this problem does not arise and views can
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
+was designed to generate a ready-to-compile \gls{TOP}-like system 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
-given classes. The following sections show the details of the \gls{EDSL}
-that are 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
+classes given. The following sections show the details of the \gls{EDSL} that
+are 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 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}
+kinded view and can, and will most often, be exclusively 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}.
Expressions in the \gls{mTask}-\gls{EDSL} are divided into two types, namely
boolean expressions and arithmetic expressions. The class of arithmetic
language constructs also contains the function \CI{lit} that lifts a
-host-language value in to the \gls{EDSL} domain. All standard arithmetic
+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
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.
+The sequence operator is very straightforward and its only function is to tie
+the together in sequence.
\begin{lstlisting}[%
label={lst:control},caption={Control flow operators}]
\section{Input/Output and class extensions}
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.
+extensions can be created for specific peripherals such as built-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.
\begin{lstlisting}[%
label={lst:sdsio},caption={Input/Output classes}]
alongside the code for the \glspl{Task}. This engine will execute the
\glspl{mTask} according to certain rules and semantics.
\glspl{mTask} do not behave like functions but more like
-\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either his timer runs
-out or when it is started by another \gls{mTask}. When an \gls{mTask} is
-queued it does not block the execution but it will return immediately while
-the actual \gls{Task} will be executed some time in the future.
+\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
+out or when it is launched by another \gls{mTask}. When an \gls{mTask} is
+queued it does not block the execution and it will return immediately while
+the actual \gls{Task} will be executed anytime in the future.
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 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.
+\gls{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]
\KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
\gls{iTasks}-backend}\label{lst:engine}
\end{algorithm}
-To achieve this in the \gls{EDSL} a \gls{Task} clas are added that work in a
+To achieve this in the \gls{EDSL} a \gls{Task} class is added that work in a
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
\end{lstlisting}
\section{Example mTask}
-Some example \glspl{mTask} using almost all of the functionality are shown in
+Some example \glspl{mTask} using almost all of their functionality are shown in
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!}
resources in the outside world. Sometimes, an update action only updates a part
of the resource. When this happens, all waiting \glspl{Task} looking at the
resource are notified of the update. However, it may be the case that
-\glspl{Task} where only looking at parts of the structure that was not updated.
+\glspl{Task} were only looking at parts of the structure that was not updated.
To solve this problem, parametric lenses were
introduced~\cite{domoszlai_parametric_2014}.
Parametric lenses add a type variable to the \gls{SDS} that is in the current
-library functions fixed to \CI{()}. When a \gls{SDS} executes a write
-operation it also provides the system with a notification predicate. This
-notification predicate is a function \CI{p -> Bool} where \CI{p} is the
-parametric lens type. This allows programmers to create a big share, and have
-\glspl{Task} only look at parts of the big share. This technique is used in the
-current system in memory shares. The \CI{IWorld} contains a map that is
-accessible through an \gls{SDS}. While all data is stored in the map, only
-\glspl{Task} looking at a specific entry are notified when the structure is
-updated. The type of the parametric lens is the key in the map.
+library functions fixed to the void type (i.e. \CI{()}). When a \gls{SDS}
+executes a write operation, it also provides the system with a notification
+predicate. This notification predicate is a function \CI{p -> Bool} where
+\CI{p} is the parametric lens type. This allows programmers to create a big
+share, and have \glspl{Task} only look at parts of the big share. This
+technique is used in the current system in memory shares. The \CI{IWorld}
+contains a map that is accessible through an \gls{SDS}. While all data is
+stored in the map, only \glspl{Task} looking at a specific entry are notified
+when the structure is updated. The type of the parametric lens is the key in
+the map.
Functionality for setting parameters is added in the system. The most important
function is the \CI{sdsFocus} function. This function is listed in
Listing~\ref{lst:focus} and allows the programmer to fix the parametric lens to
-a value.
+a specific value.
\begin{lstlisting}[label={lst:focus},
caption={Parametric lens functions}]
repositories / msc-thesis1617.git / commitdiff