process camil's notes

diff --git a/acronyms.tex b/acronyms.tex
deleted file mode 100644 (file)
index 01ac16a..0000000
--- a/acronyms.tex
+++ /dev/null
@@ -1,18 +0,0 @@
-\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}

diff --git a/glossaries.tex b/glossaries.tex
index a13ed34..ad7701a 100644 (file)
--- a/glossaries.tex
+++ b/glossaries.tex
@@ -30,3 +30,24 @@
 \newglossaryentry{Javascript}{name={\emph{Javascript}},
        description={is an imperative programming language designed to run in web
        browsers}}
 \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}

diff --git a/introduction.tex b/introduction.tex
index b7adb23..7ea1d08 100644 (file)
--- a/introduction.tex
+++ b/introduction.tex
@@ -1,25 +1,26 @@
 \section{Introduction}
 \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
 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
 
 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
 combinators.
 
 \gls{iTasks} has been proven to be useful in many fields of operation such as


@@ -28,40 +29,42 @@ 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
 \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. 
 
 \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}
 
 \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,
 
 \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
 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


@@ -82,8 +85,8 @@ communicating between the server and client.
 Appendix~\ref{app:device-interface} shows the concrete interface for the
 devices.
 
 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:
 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:


@@ -93,7 +96,7 @@ 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{%
 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{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


@@ -101,16 +104,17 @@ 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
 \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%
 
 \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.
 
 Again, this requires a reprogramming cycle every time the
 \gls{Task}-specification is changed.
 


@@ -121,9 +125,9 @@ make unsafe languages type safe. For example, \gls{Ivory} has been used in the
 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
 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
 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.

diff --git a/methods.dsl.tex b/methods.dsl.tex
index df1e198..be9d7ac 100644 (file)
--- a/methods.dsl.tex
+++ b/methods.dsl.tex
@@ -1,12 +1,15 @@
-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}
 
 \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},%
 Listing~\ref{lst:exdeep}.
 
 \begin{lstlisting}[language=Clean,label={lst:exdeep},%


@@ -21,20 +24,20 @@ Listing~\ref{lst:exdeep}.
        | Eq    DSL
 \end{lstlisting}
 Deep embedding has the advantage that it is very simple to build and the views
        | 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.
 
 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
 \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}}]
 
 \begin{lstlisting}[language=Clean,label={lst:exdeepgadt},%
        caption={A minimal deep \gls{EDSL} using \glspl{GADT}}]


@@ -60,18 +63,18 @@ the internals of the language can be hidden using monads.
 :: DSL a = DSL (Env -> a)
 
 Lit :: a -> DSL a
 :: DSL a = DSL (Env -> a)
 
 Lit :: a -> DSL a

-Lit x = \e->x
+Lit x = \e -> x

 
 Var :: String -> DSL Int
 
 Var :: String -> DSL Int

-Var i = \e->retrEnv e i
+Var i = \e -> retrEnv e i

 
 Plus :: (DSL Int) (DSL Int) -> DSL Int
 
 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 :: (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
 \end{lstlisting}
 
 The advantage of shallowly embedding a language in a host language is its


@@ -100,7 +103,7 @@ pretty printer are implemented.
 
 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
 
 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
 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 a0ec96b..5bdbbb1 100644 (file)
--- a/methods.mtask.tex
+++ b/methods.mtask.tex
@@ -2,7 +2,7 @@ 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
 \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
 \cite{plasmeijer_shallow_2016}.
 
 The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and


@@ -12,17 +12,18 @@ 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.
 
 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}]
 
 \begin{lstlisting}[%
        language=Clean,label={lst:exprhier},caption={Expression role hierarchy}]


@@ -63,13 +64,13 @@ class boolExpr v where
 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
 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}]
 
 \begin{lstlisting}[%
        language=Clean,label={lst:control},caption={Control flow operators}]


@@ -81,11 +82,11 @@ class seq v where
 \end{lstlisting}
 
 \section{Input/Output and class extensions}
 \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}]
 
 \begin{lstlisting}[%
        language=Clean,label={lst:sdsio},caption={Input/Output classes}]


@@ -114,7 +115,7 @@ class assign v where
 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
 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}[%
 \gls{mTask} and make it recognizable by the type system.
 
 \begin{lstlisting}[%


@@ -139,9 +140,9 @@ the actual \gls{Task} will be executed some time 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
 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]
 append it to the queue.
 
 \begin{algorithm}[H]

diff --git a/methods.top.tex b/methods.top.tex
index c05165a..6d47dfc 100644 (file)
--- a/methods.top.tex
+++ b/methods.top.tex
@@ -1,8 +1,8 @@
 \section{iTasks}
 \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{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
 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


@@ -42,6 +42,7 @@ enterName = enterInformation "Enter your name" []
 \end{lstlisting}
 
 \begin{figure}[H]
 \end{lstlisting}
 
 \begin{figure}[H]

+       \centering

        \begin{subfigure}{.25\textwidth}
                \centering
                \includegraphics[width=.9\linewidth]{taskex1}
        \begin{subfigure}{.25\textwidth}
                \centering
                \includegraphics[width=.9\linewidth]{taskex1}


@@ -60,8 +61,8 @@ enterName = enterInformation "Enter your name" []
        \caption{Example of a generated user interface}
 \end{figure}
 
        \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.
 
 specialization instances for these functions and show an according interface.
 Generated interfaces can be modified with decoration operators.
 

diff --git a/results.arch.tex b/results.arch.tex
index f4b615a..e33dc47 100644 (file)
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -22,13 +22,13 @@ the device software.
 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.
 
                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}.
                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}
 \end{itemize}
 
 \section{Specification}

diff --git a/thesis.tex b/thesis.tex
index 519f9c2..26697c2 100644 (file)
--- a/thesis.tex
+++ b/thesis.tex
@@ -1,9 +1,8 @@
 %&thesis
 %&thesis

-\usepackage[nonumberlist,acronyms]{glossaries}  % Glossaries and acronyms
+\usepackage[nonumberlist]{glossaries}  % Glossaries and acronyms

 \usepackage[]{algorithm2e}                      % Pseudocode
 \makeglossaries%
 
 \usepackage[]{algorithm2e}                      % Pseudocode
 \makeglossaries%
 

-\input{acronyms}

 \input{glossaries}
 
 \begin{document}
 \input{glossaries}
 
 \begin{document}