From: Mart Lubbers Date: Sun, 18 Jun 2017 07:32:16 +0000 (+0200) Subject: process george's comments in chapter 1-4 X-Git-Tag: hand-in~81 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=c7fa2f10a5c049e2ae70405630857c7873778899;p=msc-thesis1617.git process george's comments in chapter 1-4 --- diff --git a/abstract.tex b/abstract.tex index c4bb5e4..dbd59b7 100644 --- a/abstract.tex +++ b/abstract.tex @@ -1,7 +1,6 @@ -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. diff --git a/acknowledgements.tex b/acknowledgements.tex index 7dd444f..518b0ec 100644 --- a/acknowledgements.tex +++ b/acknowledgements.tex @@ -1,4 +1,4 @@ -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 diff --git a/glossaries.tex b/glossaries.tex index 748a3c6..d76add4 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -2,13 +2,13 @@ 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}} diff --git a/introduction.tex b/introduction.tex index 1f4fc9a..775a7b5 100644 --- a/introduction.tex +++ b/introduction.tex @@ -9,7 +9,7 @@ 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 +\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. @@ -28,8 +28,8 @@ incident management~\cite{lijnse_top_2013}. Interfaces are automatically 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. @@ -38,16 +38,16 @@ 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. +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 @@ -70,7 +70,7 @@ Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and 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 diff --git a/methods.dsl.tex b/methods.dsl.tex index 1a153b1..3b4181e 100644 --- a/methods.dsl.tex +++ b/methods.dsl.tex @@ -23,10 +23,11 @@ Listing~\ref{lst:exdeep}. | 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. @@ -79,9 +80,9 @@ Eq x y = \e -> x e + y e 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 @@ -91,9 +92,9 @@ implement all views rendering it slow for multiple views and complex to 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 @@ -101,9 +102,9 @@ embedding. A view is just a different data type implementing one or more of the 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 diff --git a/methods.mtask.tex b/methods.mtask.tex index df05035..4e61d97 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -1,27 +1,27 @@ 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}. @@ -40,7 +40,7 @@ instance isExpr Expr 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 @@ -72,8 +72,8 @@ 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. +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}] @@ -92,9 +92,10 @@ class seq v where \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}] @@ -140,18 +141,18 @@ The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated 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$} @@ -176,7 +177,7 @@ append it to the queue. \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 @@ -193,7 +194,7 @@ count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 100 \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!} diff --git a/methods.top.tex b/methods.top.tex index ec330c9..e6b7580 100644 --- a/methods.top.tex +++ b/methods.top.tex @@ -161,25 +161,26 @@ sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|} 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}]