+++ /dev/null
-\newacronym{GADT} {GADT} {Generalized Algebraic Datatype}
-\newacronym{GPIO} {GPIO} {General-Purpose Input/Output}
-\newacronym{ADT} {ADT} {Algebraic Datatype}
-\newacronym{SDS} {SDS} {Shared Data Source}
-\newacronym{IoT} {IoT} {Internet of Things}
-\newacronym{TOP} {TOP} {Task Oriented Programming}
-\newacronym{EDSL} {EDSL} {Embedded Domain Specific Language}
-\newacronym{RISC} {RISC} {Reduced Instruction Set Computer}
-\newacronym{ARM} {ARM} {Acorn \acrshort{RISC} Machine}
-\newacronym{LTN} {LTN} {Low Throughput Network}
-\newacronym{IDE} {IDE} {Integrated Development Environment}
-\newacronym{TCP} {TCP} {Transmission Control Protocol}
-\newacronym{RFID} {RFID} {Radio-Frequency Identification}
-\newacronym{GNSS} {GNSS} {Global Navigation SAtellite System}
-\newacronym{LCD} {LCD} {Liquid Crystal Display}
-\newacronym{AST} {AST} {Abstract Syntax Tree}
-\newacronym{GPS} {GPL} {Global Positioning System}
-\newacronym{GLONASS}{GLONASS}{Global Navigation Satellite System}
\newglossaryentry{Javascript}{name={\emph{Javascript}},
description={is an imperative programming language designed to run in web
browsers}}
+\newcommand{\newglossacr}[2]{\newglossaryentry{#1}{name={#1},first={%
+ \glsentrylong{#1} (\glsentryname{#1})},firstplural={\glsentrylong{#1}%
+ \glspluralsuffix (\glsentryname{#1}\glspluralsuffix},description={#2}}}
+\newglossacr{GADT}{Generalized Algebraic Data type}
+\newglossacr{GPIO} {General-Purpose Input/Output}
+\newglossacr{ADT} {Algebraic Datatype}
+\newglossacr{SDS} {Shared Data Source}
+\newglossacr{IoT} {Internet of Things}
+\newglossacr{TOP} {Task Oriented Programming}
+\newglossacr{EDSL} {Embedded Domain Specific Language}
+\newglossacr{RISC} {Reduced Instruction Set Computer}
+\newglossacr{ARM} {Acorn \glsentryname{RISC} Machine}
+\newglossacr{LTN} {Low Throughput Network}
+\newglossacr{IDE} {Integrated Development Environment}
+\newglossacr{TCP} {Transmission Control Protocol}
+\newglossacr{RFID} {Radio-Frequency Identification}
+\newglossacr{GNSS} {Global Navigation Satellite System}
+\newglossacr{LCD} {Liquid Crystal Display}
+\newglossacr{AST} {Abstract Syntax Tree}
+\newglossacr{GPS} {Global Positioning System}
+\newglossacr{GLONASS}{Global Navigation Satellite System}
\section{Introduction}
-\Gls{IoT} technology is emerging very quickly and offers myriads of solutions
+\Gls{IoT} technology is emerging very quickly. It offers myriads of solutions
and transforms the way we interact with technology.
Initially the term was coined to describe \gls{RFID} devices and the
communication between them. However, currently the term \gls{IoT} encompasses
all small devices that communicate with each other and the world. These devices
-often contain sensors, \gls{GNSS}\footnote{e.g.\ the American \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 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.
+are often equipped with sensors, \gls{GNSS}\footnote{e.g.\ the American
+\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
+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.
The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer
a high abstraction level for real life workflow tasks%
\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
-an \gls{EDSL} and modeled as \glspl{Task}. The system will generatea multi-user
-web service from the specification. This web service can be accessed
-through a browser and is used to complete these \glspl{Task}. Familiar workflow
-patterns like sequence, parallel and conditional tasks can be modelled using
+an \gls{EDSL} and modeled as \glspl{Task}. The system will generate multi-user
+web app from the specification. This web service can be accessed through a
+browser and is used to complete these \glspl{Task}. Familiar workflow patterns
+like sequence, parallel and conditional tasks can be modelled using
combinators.
\gls{iTasks} has been proven to be useful in many fields of operation such as
\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 \emph{performed} by small
+them 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.
-In the current system such adapters, in principle, can be written as
-\glspl{SDS}\footnote{Similar as to resources such as time are available in
-the current \gls{iTasks} implementation} but this requires a very specific
-adapter to be written for every device and function. However, 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.
+In the current system such adapters connecting devices to \gls{iTasks} --- in
+principle --- can be written as \glspl{SDS}\footnote{Similar as to resources
+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.
\section{Problem statement}
-The updates to the \gls{mTask}-system will bridge this gap by introducing a new
-communication protocol, device application and \glspl{Task} synchronizing the
-formers. The system can run on devices as small as \gls{Arduino}
-microcontrollers\cite{noauthor_arduino_nodate} and operates via the same
-paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
-Devices in the \glspl{mTask}-system can run small imperative programs written
-in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
-device at runtime, avoiding recompilation and thus write cycles on the program
-memory.
+The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will
+bridge this gap by introducing a new communication protocol, device application
+and \glspl{Task} synchronizing the formers. The system can run on devices as
+small as \gls{Arduino} microcontrollers\cite{noauthor_arduino_nodate} and
+operates via the same paradigms and patterns as regular \glspl{Task} in the
+\gls{TOP} paradigm. Devices in the \gls{mTask}-system can run small imperative
+programs written in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task}
+are sent to the device at runtime, avoiding recompilation and thus write cycles
+on the program memory.
\section{Document structure}
The structure of this thesis is as follows.
Chapter~\ref{chp:introduction} contains the problem statement, motivation,
-literature embedding and the structure of the document.
+related work and the structure of the document.
Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
\gls{iTasks}.
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
Appendix~\ref{app:device-interface} shows the concrete interface for the
devices.
-\section{Relevant research}
-Several types of similar research has been conducted concerning these matters.
+\section{Related work}
+Several types of similar research have been conducted concerning these matters.
Microcontrollers such as the \gls{Arduino} can be remotely controlled by the
\gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the
Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed:
overhead since no code is executed on the device, only the peripherals are
queried. A \gls{Haskell} implementation of the protocol has been created%
\footnote{``hArduino by LeventErkok.'' (\url{%
-https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}
+https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
\Gls{Clean} has a history of interpretation and there is a lot of research
happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
\gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}%
\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
backends\cite{domoszlai_compiling_2012}. However, interpreting the resulting
-code is still heap-heavy therefore not directly suitable for devices with as
-few as $2K$ of RAM such as the \gls{Arduino}. It might be possible to compile
-the \gls{SAPL} code into efficient machine language or \gls{C} but then the
-system would lose its dynamic properties since the microcontroller then would
-has to be reprogrammed every time a new \gls{Task} is sent to the device.
+code is still heap-heavy and therefore not directly suitable for devices with as
+little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
+possible to compile the \gls{SAPL} code into efficient machine language or
+\gls{C} but then the system would lose its dynamic properties since the
+microcontroller then would have to be reprogrammed every time a new \gls{Task}
+is sent to the device.
\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
-\cite{plasmeijer_shallow_2016}.\cite{koopman_type-safe_nodate}.
+\cite{plasmeijer_shallow_2016}\cite{koopman_type-safe_nodate}.
Again, this requires a reprogramming cycle every time the
\gls{Task}-specification is changed.
automotive industry to program parts of an autopilot%
\cite{pike_programming_2014}\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
is deeply embedded but the type system is shallowly embedded. This requires
-several \gls{Haskell} extensions that offer dependant type constructions. The
+several \gls{Haskell} extensions that offer dependent type constructions. The
process of compiling an \gls{Ivory} program happens in stages. The embedded
code is transformed into an \gls{AST} that is sent to a backend. The
-\gls{mTask} \gls{EDSL} transform the embedded code during compile-time directly
-into the backend which is often a state transformer that will execute on
-runtime.
+\gls{mTask} \gls{EDSL} transforms the embedded code during compile-time
+directly into the backend which is often a state transformer that will execute
+on runtime.
-There are several techniques available for creating \glspl{EDSL}. Each of
-them have their own advantages and disadvantages such as extendability,
-typedness and view support. In the following subsections each of the main
-techniques are briefly explained.
+An \gls{EDSL} is a language embedded in a host language. \glspl{EDSL} can have
+one or more backends or views. Commonly used views are pretty printing,
+compiling, simulating, verifying and proving the program. There are several
+techniques available for creating \glspl{EDSL}. Each of them have their own
+advantages and disadvantages in terms of extendability, typedness and view
+support. In the following subsections each of the main techniques are briefly
+explained.
\section{Deep embedding}
-A deep \gls{EDSL} means that the language is represented as an \gls{ADT}. Views
-are functions that transform something to the datatype or the other way around.
-As an example we have the simple arithmetic \gls{EDSL} shown in
+A deep \gls{EDSL} is a language represented as an \gls{ADT}. Views are
+functions that transform something to the datatype or the other way around. As
+an example we have the simple arithmetic \gls{EDSL} shown in
Listing~\ref{lst:exdeep}.
\begin{lstlisting}[language=Clean,label={lst:exdeep},%
| Eq DSL
\end{lstlisting}
Deep embedding has the advantage that it is very simple to build and the views
-are easy to make and add. To the downside, the expressions created with this
-language are not type-safe. In the given language it is possible an expression
-such as \CI{Plus (LitI 4) (LitB True)} which to add a boolean to an integer.
+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.
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 first downside of the type of \gls{EDSL} can be overcome by using
+The first downside of this type of \gls{EDSL} can be overcome by using
\glspl{GADT}\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
the same language, but type-safe with a \gls{GADT}. \glspl{GADT} are not
supported in the current version of \gls{Clean} and therefore the syntax is
-artificial. However, it has been shown that \glspl{GADT} can be simulated using
-bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately the
-lack of extendability remains a problem. If a language construct is added, no
-compile time guarantee is given that all views support it.
+hypothetical. However, it has been shown that \glspl{GADT} can be simulated
+using bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately
+the lack of extendability remains a problem. If a language construct is added,
+no compile time guarantee is given that all views support it.
\begin{lstlisting}[language=Clean,label={lst:exdeepgadt},%
caption={A minimal deep \gls{EDSL} using \glspl{GADT}}]
:: DSL a = DSL (Env -> a)
Lit :: a -> DSL a
-Lit x = \e->x
+Lit x = \e -> x
Var :: String -> DSL Int
-Var i = \e->retrEnv e i
+Var i = \e -> retrEnv e i
Plus :: (DSL Int) (DSL Int) -> DSL Int
-Plus x y = \e->x e + y e
+Plus x y = \e -> x e + y e
...
Eq :: (DSL a) (DSL a) -> DSL Bool | == a
-Eq x y = \e->x e + y e
+Eq x y = \e -> x e + y e
\end{lstlisting}
The advantage of shallowly embedding a language in a host language is its
Just as with \glspl{GADT} in deep embedding type safety is guaranteed. Type
constraints are enforced through phantom types. One can add as many phantom
-type as is necessary. Lastly, extensions can be added easily, just as in
+type 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
\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\todo{explain} 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.
\begin{lstlisting}[%
language=Clean,label={lst:control},caption={Control flow operators}]
\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 LEDs. 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]
\section{iTasks}
-\gls{TOP} is a recent programming paradigm implemented as
+\gls{TOP} is a modern recent programming paradigm implemented as
\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
-\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just
+\gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just
a function that --- given some state --- returns the observable \CI{TaskValue}. The
\CI{TaskValue} of a \CI{Task} can have different states. Not all state
transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value
\end{lstlisting}
\begin{figure}[H]
+ \centering
\begin{subfigure}{.25\textwidth}
\centering
\includegraphics[width=.9\linewidth]{taskex1}
\caption{Example of a generated user interface}
\end{figure}
-For a type to be suitable it must have instances for a collection of generic
-functions that are captured in the class \CI{iTask}. Basic types have
+For a type to be suitable, it must have instances for a collection of generic
+functions that is captured in the class \CI{iTask}. Basic types have
specialization instances for these functions and show an according interface.
Generated interfaces can be modified with decoration operators.
This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
development board.
- \item Microcontrollers programmable by the \emph{Arduino} \gls{IDE}.\\
+ \item Microcontrollers programmable by the \gls{Arduino} \gls{IDE}.\\
- This does not only include \emph{Arduino} compatible boards but also
- other boards capable of running \emph{Arduino} code. The code
+ This does not only include \gls{Arduino} compatible boards but also
+ other boards capable of running \gls{Arduino} code. The code
has been found working on the \texttt{ESP8266} powered \emph{NodeMCU}.
- It is tested on devices as small as the regular \emph{Arduino UNO}
- board that only boasts a meager \emph{2K} of \emph{RAM}.
+ It is tested on devices as small as the regular \gls{Arduino}
+ \emph{UNO} board that only boasts a meager \emph{2K} of \emph{RAM}.
\end{itemize}
\section{Specification}
%&thesis
-\usepackage[nonumberlist,acronyms]{glossaries} % Glossaries and acronyms
+\usepackage[nonumberlist]{glossaries} % Glossaries and acronyms
\usepackage[]{algorithm2e} % Pseudocode
\makeglossaries%
-\input{acronyms}
\input{glossaries}
\begin{document}
repositories / msc-thesis1617.git / commitdiff