From 98871c8ad188e85dd4fed2fe19ebd2c8687f01d7 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 19 Jun 2017 18:27:20 +0200 Subject: [PATCH] big final sweep --- introduction.tex | 32 ++++++++++------- methods.mtask.tex | 25 ++++++++------ methods.top.tex | 87 +++++++++++++++++++++++++---------------------- thesis.tex | 2 +- 4 files changed, 82 insertions(+), 64 deletions(-) diff --git a/introduction.tex b/introduction.tex index 8d5de43..66d6b66 100644 --- a/introduction.tex +++ b/introduction.tex @@ -88,17 +88,25 @@ Text written using the \CI{Teletype} font indicates code and is often 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 @@ -107,8 +115,8 @@ functional intermediate language that has interpreters written in \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} diff --git a/methods.mtask.tex b/methods.mtask.tex index d6fcbb3..72e66d1 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -1,8 +1,8 @@ -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 @@ -43,7 +43,7 @@ language constructs also contains the function \CI{lit} that lifts a 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}, @@ -93,7 +93,7 @@ class seq v where 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. @@ -122,10 +122,12 @@ class assign v where \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}}] @@ -201,7 +203,10 @@ to a particular view and therefore are of the type \CI{View t r}. The 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}}] diff --git a/methods.top.tex b/methods.top.tex index aefa35d..811e12a 100644 --- a/methods.top.tex +++ b/methods.top.tex @@ -1,13 +1,13 @@ \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 @@ -63,47 +63,23 @@ enterName = enterInformation "Enter your name" [] 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) @@ -118,14 +94,43 @@ Listing~\ref{lst:combinators}. (-&&-) 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 diff --git a/thesis.tex b/thesis.tex index 045fc46..5be4938 100644 --- a/thesis.tex +++ b/thesis.tex @@ -43,7 +43,7 @@ \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} -- 2.20.1