referring to a listing. \emph{Emphasized} text is used for proper nouns and
words that have a unexpected meaning.
+The complete source code of this thesis can be found in the following git
+repository:\\
+\url{https://git.martlubbers.net/msc-thesis1617.git}
+
+The complete source code of the \gls{mTask}-system can be found in the
+following git repository:
+\url{https://git.martlubbers.net/mTask.git}
+
\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:
-23-May-2017].}. This protocol
-is designed to expose the peripherals such as sensors to the server. This
-allows very fine grained control but with the cost of excessive communication
-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{%
+Similar research has been conducted concerning these matters.
+For example, 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: 23-May-2017].}. This
+protocol is designed to expose the peripherals such as sensors to the server.
+This allows very fine grained control but with the cost of excessive
+communication overhead since no code is executed on the device, only the
+peripherals are queried. A \gls{Haskell} implementation of the protocol is
+also available\footnote{``hArduino by LeventErkok.'' (\url{%
https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
\Gls{Clean} has a history of interpretation and there is a lot of research
\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 and therefore not directly suitable for devices with as
-little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
+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}
-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},
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}}]
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}}]
\section{iTasks}
-\gls{TOP} is a modern recent programming paradigm implemented as
+\gls{TOP} is a novel 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
+language \gls{Clean}~\cite{brus_cleanlanguage_1987}. \gls{iTasks} is an
\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
+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
-is stable it can never become unstable again. Stability is often reached
-by pressing a confirmation button. \glspl{Task} yielding a constant value are
+is stable it can never become unstable again. Stability is often reached by
+pressing a confirmation button. \glspl{Task} yielding a constant value are
immediately stable.
A simple \gls{iTasks} example illustrating the route to stability of a
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.
+specialization instances for these functions and show an interface accordingly.
+Derived interfaces can be modified with decoration operators or specializations
+can be created.
\section{Combinators}
\Glspl{Task} can be combined using so called \gls{Task}-combinators.
-Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
-combined in parallel, sequenced and their result values can be converted to
-\glspl{SDS}. Moreover, a very important combinator is the step combinator which
-starts a new \gls{Task} according to specified predicates on the
-\CI{TaskValue}. Type signatures of the basic combinators are shown in
-Listing~\ref{lst:combinators}.
-
-\begin{itemize}
- \item Step:
-
- The step combinator is used to start \glspl{Task} when a predicate on
- the \CI{TaskValue} holds or an action has taken place. The bind
- operator can be written as a step combinator.
- \begin{lstlisting}[language=Clean]
-(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
-(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
- where
- onValue (Value a _) = Just (f a)
- onValue _ = Nothing
-
- onStable (Value a True) = Just (f a)
- onStable _ = Nothing
- \end{lstlisting}
- \item Parallel:
-
- The parallel combinator allows for concurrent \glspl{Task}. The
- \glspl{Task} combined with these operators will appear at the same time
- in the web browser of the user and the results are combined as the type
- dictates.
-\end{itemize}
+Combinators describe relations between \glspl{Task}. There are only two basic
+types of combinators; namely parallel and sequence. All other combinators are
+derived from the basic combinators. Type signatures of simplified versions of
+the basic combinators and their derivations are given in
+Listing~\ref{lst:combinators}
\begin{lstlisting}[%
caption={\Gls{Task}-combinators},label={lst:combinators}]
//Step combinator
-(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
(>>=) infixl 1 :: (Task a) (a -> Task b) -> Task b | iTask a & iTask b
+(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
:: TaskCont a b
= OnValue ((TaskValue a) -> Maybe b)
| OnAction Action ((TaskValue a) -> Maybe b)
(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
\end{lstlisting}
+\paragraph{Sequence:}
+The implementation for the sequence combinator is called the
+\CI{step} (\CI{>>*}). This combinator runs the left-hand \gls{Task} and
+starts the right-hand side when a certain predicate holds. Predicates
+can be propositions about the \CI{TaskValue}, user actions from within
+the web browser or a thrown exception. The familiar
+bind-combinator is an example of a sequence combinator. This combinator
+runs the left-hand side and continues to the right-hand \gls{Task} if
+there is an \CI{UnStable} value and the user presses continue or when
+the value is \CI{Stable}. The combinator could have been implemented
+as follows:
+\begin{lstlisting}[language=Clean]
+(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
+(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
+ where
+ onValue (Value a _) = Just (f a)
+ onValue _ = Nothing
+
+ onStable (Value a True) = Just (f a)
+ onStable _ = Nothing
+\end{lstlisting}
+
+\paragraph{Parallel:}
+The parallel combinator allows for concurrent \glspl{Task}. The
+\glspl{Task} combined with these operators will appear at the same time
+in the web browser of the user and the results are combined as the type
+dictates. All parallel combinators used are derived from the basic parallel
+combinator that is very complex and only used internally.
+
\section{Shared Data Sources}
\Glspl{SDS} are an abstraction over resources that are available in the world
or in the \gls{iTasks} system. The shared data can be a file on disk, the
system time, a random integer or just some data stored in memory. The actual
\gls{SDS} is just a record containing functions on how to read and write the
source. In these functions the \CI{*IWorld} --- which in turn contains the real
-program \CI{*World} --- is available. Accessing the outside world is required
-for interacting with it and thus the functions can access files on disk, raw
+\CI{*World} --- is available. Accessing the outside world is required for
+interacting with it and thus the functions can access files on disk, raw
memory, other \glspl{SDS} and hardware.
The basic operations for \glspl{SDS} are get, set and update. The signatures
\chapter{Task Oriented Programming}\label{chp:top}
\input{methods.top}
-\chapter{Embedded Domain Specific Language}\label{chp:dsl}
+\chapter{Embedded Domain Specific Languages}\label{chp:dsl}
\input{methods.dsl}
\chapter{The mTask EDSL}\label{chp:mtask}
repositories / msc-thesis1617.git / commitdiff