comments comemnts comments

diff --git a/appx/bytecode.tex b/appx/bytecode.tex
index ce6c4df..12e1c82 100644 (file)
--- a/appx/bytecode.tex
+++ b/appx/bytecode.tex
@@ -2,32 +2,35 @@
 
 \input{subfilepreamble}
 
 
 \input{subfilepreamble}
 

-\setcounter{chapter}{2}

 
 \begin{document}
 \input{subfileprefix}
 
 \begin{document}
 \input{subfileprefix}

-\ifSubfilesClassLoaded{\appendix}{}
+\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{2}}{}

 \chapter{Bytecode instruction set}%
 \label{chp:bytecode_instruction_set}%
 \chapter{Bytecode instruction set}%
 \label{chp:bytecode_instruction_set}%

-This appendix describeds the semantics of the byte code instruction set.
-The byte code instructions are of variable length and automatically encoded and decoded using generic programming (see \todo{ref naar c\-co\-de\-gen}).
+This appendix describeds the semantics of the byte code instruction set of \gls{MTASK} (see \cref{chp:implementation}).
+The byte code instructions are of variable length and automatically encoded and decoded using generic programming (see \cref{sec:ccodegen}).

 \Cref{tbl:bc_notation} shows the notation convention.
 \Cref{tbl:bc_notation} shows the notation convention.

+\Cref{tbl:instr_task} shows the semantics of all major byte code instructions, shorthand instructions and auxiliary peripherals have been omitted for brevity but have the analogous semantics as their counterparts.

 
 

-\begin{table}[ht!]
-       \caption{Notation for the byte code semantics}%
+\begin{table}
+       \caption{Notation convention for the byte code semantics.}%

        \label{tbl:bc_notation}
        \centering
        \begin{tabular}{lll}
                \toprule
                variable & meaning & \textnumero{}bytes\\
                \midrule
        \label{tbl:bc_notation}
        \centering
        \begin{tabular}{lll}
                \toprule
                variable & meaning & \textnumero{}bytes\\
                \midrule

+               $fp$ & frame pointer & 2\\
+               $sp$ & stack pointer & 2\\
+               $pc$ & program counter & 2\\

                $l$ & label & 2\\
                $l$ & label & 2\\

+               \midrule

                $w_r$ & return width & 1\\
                $w_a$ & argument width & 1\\
                $i$ & \gls{SDS} or sensor id & 1\\
                $w_r$ & return width & 1\\
                $w_a$ & argument width & 1\\
                $i$ & \gls{SDS} or sensor id & 1\\

-               $fp$ & frame pointer & 2\\
-               $sp$ & stack pointer & 2\\
-               $pc$ & program counter & 2\\
+               $n$ & number & 1\\
+               $d$ & depth & 1\\

                \bottomrule
        \end{tabular}
 \end{table}
                \bottomrule
        \end{tabular}
 \end{table}


@@ -48,8 +51,7 @@ The byte code instructions are of variable length and automatically encoded and
                \endfoot%
                \bottomrule
                \endlastfoot%
                \endfoot%
                \bottomrule
                \endlastfoot%

-               \texttt{push}     & $n~b_0\ldots b_n$   & $st[sp+i] = s[i]$                             & $sp+n$           & $pc+2+n$\\
-                                             &                     & {\bf for all} $i\in\{0..n\}$\\
+               \texttt{push}     & $n~b_0\ldots b_n$   & $st[sp+i] = s[i]$ {\bf for all} $i\in\{0..n\}$                            & $sp+n$           & $pc+2+n$\\

                \texttt{pop}      & $n$                 & & $sp\shortminus{}n$           & $pc+2$\\
                \texttt{rot}      & $d~n$               & $rotate\:(d, n)$                              & $sp$             & $pc+3$\\
                \texttt{dup}      &                     & $st[sp] = st[sp\shortminus{}1]$                           & $sp+1$           & $pc+1$\\
                \texttt{pop}      & $n$                 & & $sp\shortminus{}n$           & $pc+2$\\
                \texttt{rot}      & $d~n$               & $rotate\:(d, n)$                              & $sp$             & $pc+3$\\
                \texttt{dup}      &                     & $st[sp] = st[sp\shortminus{}1]$                           & $sp+1$           & $pc+1$\\


@@ -60,7 +62,7 @@ The byte code instructions are of variable length and automatically encoded and
                \texttt{tailCall} & $w_{a_1}~w_{a_2}~l$ & $rotate\:(w_{a_1}+3+w_{a_2},w_{a_2})$         & $fp$             & $jl$\\
                                                  &                     & $fp = fp\shortminus{}w_{a_1}+w_{a_2}$\\
                                                  &                     & \multicolumn{3}{p{.75\textwidth}}{{\bf where} $w_{a_1}$ is the width of the current function and $w_{a_2}$ the width of the called function}\\
                \texttt{tailCall} & $w_{a_1}~w_{a_2}~l$ & $rotate\:(w_{a_1}+3+w_{a_2},w_{a_2})$         & $fp$             & $jl$\\
                                                  &                     & $fp = fp\shortminus{}w_{a_1}+w_{a_2}$\\
                                                  &                     & \multicolumn{3}{p{.75\textwidth}}{{\bf where} $w_{a_1}$ is the width of the current function and $w_{a_2}$ the width of the called function}\\

-               \texttt{arg}      & $i$                 & $st[sp] = st[fp\shortminus{}1\shortminus{}i]$ & $sp+1$\\
+               \texttt{arg}      & $n$                 & $st[sp] = st[fp\shortminus{}1\shortminus{}n]$ & $sp+1$\\

                \texttt{return}   & $w_r~w_a$           & $st[fp\shortminus{}w_a\shortminus{}3+i] = st[fp+1]$ & $st[fp\shortminus{}w_a\shortminus{}3+w_r]$ & $st[fp\shortminus{}w_a\shortminus{}1]$\\
                                              &                     & {\bf for all} $i\in\{0..w_r\}$\\
                                              &                     & $fp = st[fp\shortminus{}w_a\shortminus{}2]$\\
                \texttt{return}   & $w_r~w_a$           & $st[fp\shortminus{}w_a\shortminus{}3+i] = st[fp+1]$ & $st[fp\shortminus{}w_a\shortminus{}3+w_r]$ & $st[fp\shortminus{}w_a\shortminus{}1]$\\
                                              &                     & {\bf for all} $i\in\{0..w_r\}$\\
                                              &                     & $fp = st[fp\shortminus{}w_a\shortminus{}2]$\\


@@ -68,42 +70,41 @@ The byte code instructions are of variable length and automatically encoded and
                                                  &                     & $st[sp+1] = fp$\\
                                  &                     & $st[sp+2] = 0$\\
                \midrule
                                                  &                     & $st[sp+1] = fp$\\
                                  &                     & $st[sp+2] = 0$\\
                \midrule

-               \texttt{unOp}     &                     & $st[sp\shortminus{}1] = \diamond{}st[sp\shortminus{}1]$                & $sp$             & $pc+1$\\
-                                                 &                     & \multicolumn{3}{l}{{\bf for all} $\diamond\in\{\neg\}$}\\
+               \texttt{unOp}     &                     & $st[sp\shortminus{}1] = \diamond{}st[sp\shortminus{}1]$ {\bf for all} $\diamond\in\{\neg\}$               & $sp$             & $pc+1$\\

                \texttt{binOp}    &                     & $st[sp\shortminus{}2] = st[sp\shortminus{}2] \mathbin{\oplus} st[sp\shortminus{}1]$         & $sp\shortminus{}1$           & $pc+1$\\
                                                  &                     & \multicolumn{3}{l}{{\bf for all} $\oplus\in\{+, \shortminus{}, *, /, \wedge, \vee, \equiv, \not\equiv, \leq, \geq, <, >\}$}\\
                \texttt{binOp}    &                     & $st[sp\shortminus{}2] = st[sp\shortminus{}2] \mathbin{\oplus} st[sp\shortminus{}1]$         & $sp\shortminus{}1$           & $pc+1$\\
                                                  &                     & \multicolumn{3}{l}{{\bf for all} $\oplus\in\{+, \shortminus{}, *, /, \wedge, \vee, \equiv, \not\equiv, \leq, \geq, <, >\}$}\\

-                                                 &                     & \multicolumn{3}{l}{similar for Real and Long variants}\\
-               \texttt{cast}\textsubscript{f-t}     &  & $st[sp\shortminus{}1] = cast_{f-t} (st[sp\shortminus{}1])$ & $sp$ & $pc+1$\\
+                                                 &                     & \multicolumn{3}{l}{similar for \cleaninline{Real} and \cleaninline{Long} variants}\\
+               \texttt{cast}\textsubscript{f-t}     &  & $st[sp\shortminus{}1] = cast_{f\shortminus{}-t} (st[sp\shortminus{}1])$ & $sp$ & $pc+1$\\

                                                  &                     & \multicolumn{3}{l}{{\bf for all} $f,t\in\{Int, Real, Long\}$}\\
 %              \pagebreak
                \texttt{mkTask}   & \texttt{Stable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (stable,$              & $sp\shortminus{}n+1$ & $pc+2$\\
                                                  &                                  & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\
                                                  &                     & \multicolumn{3}{l}{{\bf for all} $f,t\in\{Int, Real, Long\}$}\\
 %              \pagebreak
                \texttt{mkTask}   & \texttt{Stable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (stable,$              & $sp\shortminus{}n+1$ & $pc+2$\\
                                                  &                                  & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\

-                                                 & \texttt{Unstable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (unstable,$          & $sp\shortminus{}n+1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{Unstable\textsubscript{n}} & $st[sp\shortminus{}n\shortminus{}1] = node (unstable,$          & $sp\shortminus{}n+1$ & $pc+2$\\

                                                  &                                  & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\
                \midrule
                                                  &                                  & $\qquad\qquad st[sp\shortminus{}1], \ldots, st[sp\shortminus{}n\shortminus{}1])$\\
                \midrule

-                                                 & \texttt{ReadD}          & $st[sp\shortminus{}1] = node (readd, st[sp\shortminus{}1])$                 & $sp$      & $pc+2$\\
-                                                 & \texttt{ReadA}          & $st[sp\shortminus{}1] = node (reada, st[sp\shortminus{}1])$                 & $sp$      & $pc+2$\\
-                                                 & \texttt{WriteD}         & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{WriteA}         & $st[sp\shortminus{}2] = node (writea, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{WriteD}         & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{PinMode}        & $st[sp\shortminus{}2] = node (pinmode, st[sp\shortminus{}1], st[sp\shortminus{}2])$   & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{ReadD}          & $st[sp\shortminus{}1] = node (readd, st[sp\shortminus{}1])$                 & $sp$      & $pc+2$\\
+               \texttt{mkTask}   & \texttt{ReadA}          & $st[sp\shortminus{}1] = node (reada, st[sp\shortminus{}1])$                 & $sp$      & $pc+2$\\
+               \texttt{mkTask}   & \texttt{WriteD}         & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{WriteA}         & $st[sp\shortminus{}2] = node (writea, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{WriteD}         & $st[sp\shortminus{}2] = node (writed, st[sp\shortminus{}1], st[sp\shortminus{}2])$    & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{PinMode}        & $st[sp\shortminus{}2] = node (pinmode, st[sp\shortminus{}1], st[sp\shortminus{}2])$   & $sp\shortminus{}1$ & $pc+2$\\

                \midrule
                \midrule

-                                                 & \texttt{Repeat}         & $st[sp] = node (repeat, st[sp\shortminus{}1])$              & $sp$   & $pc+2$\\
-                                                 & \texttt{Delay}          & $st[sp] = node (delay, st[sp\shortminus{}1])$               & $sp$   & $pc+2$\\
-                                                 & \texttt{And}            & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$       & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{Or}             & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$       & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{Step} $f$ $w_a$ & $st[sp] = node (step, st[sp\shortminus{}1], f, w)$          & $sp$   & $pc+5$\\
+               \texttt{mkTask}   & \texttt{Repeat}         & $st[sp] = node (repeat, st[sp\shortminus{}1])$              & $sp$   & $pc+2$\\
+               \texttt{mkTask}   & \texttt{Delay}          & $st[sp] = node (delay, st[sp\shortminus{}1])$               & $sp$   & $pc+2$\\
+               \texttt{mkTask}   & \texttt{And}            & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$       & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{Or}             & $st[sp\shortminus{}1] = node (and, st[sp\shortminus{}1], st[sp\shortminus{}2])$       & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{Step} $f$ $w_a$ & $st[sp] = node (step, st[sp\shortminus{}1], f, w)$          & $sp$   & $pc+5$\\

                \midrule
                \midrule

-                                                 & \texttt{SdsGet} $i$     & $st[sp+1]   = node (sdsget, i)$                   & $sp+1$ & $pc+3$\\
-                                                 & \texttt{SdsSet} $i$     & $st[sp\shortminus{}1] = node (sdsset, st[sp\shortminus{}1], i)$           & $sp$   & $pc+3$\\
-                                                 & \texttt{SdsUpd} $i$ $l$ & $st[sp+1] = node (sdsset, i, l)$                  & $sp+1$ & $pc+5$\\
+               \texttt{mkTask}   & \texttt{SdsGet} $i$     & $st[sp+1]   = node (sdsget, i)$                   & $sp+1$ & $pc+3$\\
+               \texttt{mkTask}   & \texttt{SdsSet} $i$     & $st[sp\shortminus{}1] = node (sdsset, st[sp\shortminus{}1], i)$           & $sp$   & $pc+3$\\
+               \texttt{mkTask}   & \texttt{SdsUpd} $i$ $l$ & $st[sp+1] = node (sdsset, i, l)$                  & $sp+1$ & $pc+5$\\

                \midrule
                \midrule

-                                                 & \texttt{Interrupt}      & $st[sp\shortminus{}2] = node (interrupt, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\
-                                                 & \texttt{RateLimit}      & $st[sp\shortminus{}1] = node (ratelimit, st[sp\shortminus{}1])$           & $sp$   & $pc+2$\\
-                                                 & \texttt{TuneRate}       & $st[sp\shortminus{}1] = node (tunerate,  st[sp\shortminus{}1], st[sp\shortminus{}2])$           & $sp\shortminus{}1$   & $pc+2$\\
+               \texttt{mkTask}   & \texttt{Interrupt}      & $st[sp\shortminus{}2] = node (interrupt, st[sp\shortminus{}1], st[sp\shortminus{}2])$ & $sp\shortminus{}1$ & $pc+2$\\
+               \texttt{mkTask}   & \texttt{RateLimit}      & $st[sp\shortminus{}1] = node (ratelimit, st[sp\shortminus{}1])$           & $sp$   & $pc+2$\\
+               \texttt{mkTask}   & \texttt{TuneRate}       & $st[sp\shortminus{}1] = node (tunerate,  st[sp\shortminus{}1], st[sp\shortminus{}2])$           & $sp\shortminus{}1$   & $pc+2$\\

                \midrule
                \midrule

-                                                 & \texttt{DHTTemp} $i$    & $st[sp+1] = node (dhttemp, i)$                    & $sp+1$ & $pc+3$\\
-                                                 & \texttt{DHTHumid} $i$   & $st[sp+1] = node (dhthumid, i)$                   & $sp+1$ & $pc+3$\\
+               \texttt{mkTask}   & \texttt{DHTTemp} $i$    & $st[sp+1] = node (dhttemp, i)$                    & $sp+1$ & $pc+3$\\
+               \texttt{mkTask}   & \texttt{DHTHumid} $i$   & $st[sp+1] = node (dhthumid, i)$                   & $sp+1$ & $pc+3$\\

        \end{longtable}
 \end{landscape}
 
        \end{longtable}
 \end{landscape}
 

diff --git a/appx/c4hp.tex b/appx/c4hp.tex
index 5f8875c..5b8e099 100644 (file)
--- a/appx/c4hp.tex
+++ b/appx/c4hp.tex
@@ -2,15 +2,13 @@
 
 \input{subfilepreamble}
 
 
 \input{subfilepreamble}
 

-\setcounter{chapter}{0}
-

 \begin{document}
 \input{subfileprefix}
 \ifSubfilesClassLoaded{\appendix}{}
 \chapter{\texorpdfstring{\glsentrytext{CLEAN}}{Clean} for \texorpdfstring{\glsentrytext{HASKELL}}{Haskell} Programmers}%
 \label{chp:clean_for_haskell_programmers}
 
 \begin{document}
 \input{subfileprefix}
 \ifSubfilesClassLoaded{\appendix}{}
 \chapter{\texorpdfstring{\glsentrytext{CLEAN}}{Clean} for \texorpdfstring{\glsentrytext{HASKELL}}{Haskell} Programmers}%
 \label{chp:clean_for_haskell_programmers}
 

-This note is meant to give people who are familiar with the \gls{FP} language \gls{HASKELL} a consise overview of \gls{CLEAN} language elements and how they differ from \gls{HASKELL}.
+This appendix is meant to give people who are familiar with the \gls{FP} language \gls{HASKELL} a consise overview of the \gls{CLEAN} language elements and how they differ from \gls{HASKELL}.

 The goal is to support the reader when reading \gls{CLEAN} code.
 \Cref{tbl:syn_clean_haskell} shows frequently occuring \gls{CLEAN} language elements on the left side and their \gls{HASKELL} equivalent on the right side.
 Obviously, this summary is not exhaustive.
 The goal is to support the reader when reading \gls{CLEAN} code.
 \Cref{tbl:syn_clean_haskell} shows frequently occuring \gls{CLEAN} language elements on the left side and their \gls{HASKELL} equivalent on the right side.
 Obviously, this summary is not exhaustive.

diff --git a/appx/mtask_aux.tex b/appx/mtask_aux.tex
index 74273a4..54812ff 100644 (file)
--- a/appx/mtask_aux.tex
+++ b/appx/mtask_aux.tex
@@ -2,11 +2,10 @@
 
 \input{subfilepreamble}
 
 
 \input{subfilepreamble}
 

-\setcounter{chapter}{1}

 
 \begin{document}
 \input{subfileprefix}
 
 \begin{document}
 \input{subfileprefix}

-\ifSubfilesClassLoaded{\appendix}{}
+\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{1}}{}

 \chapter{Auxiliary \texorpdfstring{\glsentrytext{MTASK}}{mTask} type classes}%
 \label{chp:mtask_aux}
 \lstset{basicstyle=\tt\footnotesize}
 \chapter{Auxiliary \texorpdfstring{\glsentrytext{MTASK}}{mTask} type classes}%
 \label{chp:mtask_aux}
 \lstset{basicstyle=\tt\footnotesize}

diff --git a/asbook.tex b/asbook.tex
index a6e7816..5e6301d 100644 (file)
--- a/asbook.tex
+++ b/asbook.tex
@@ -4,7 +4,7 @@
 \usepackage{pdfpages}
 
 \begin{document}
 \usepackage{pdfpages}
 
 \begin{document}

-\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8
-%\includepdf[landscape,booklet,pages={1-}]{top/4iot.pdf}%chktex 29 chktex 8
+%\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8
+\includepdf[landscape,booklet,pages={1-}]{concl/concl.pdf}%chktex 29 chktex 8

 %\includepdf[pages={211,212}]{thesis.pdf}%chktex 29 chktex 8
 \end{document}
 %\includepdf[pages={211,212}]{thesis.pdf}%chktex 29 chktex 8
 \end{document}

diff --git a/back/acknowledgements.tex b/back/acknowledgements.tex
index f065479..c159e0c 100644 (file)
--- a/back/acknowledgements.tex
+++ b/back/acknowledgements.tex
@@ -47,7 +47,7 @@ Michel de Boer,
 Sjoerd Crooijmans,
 Willem de Vos.
 
 Sjoerd Crooijmans,
 Willem de Vos.
 

-I give special thanks to my mentors who never stopped having faith me:
+I give special thanks to my mentors:

 Jos Baack, Francisco Torreira, Franc Grootjen, Louis Vuurpijl, and Larry Caruthers.
 
 And of course my friends and acquaintances that supported me throughout the process.
 Jos Baack, Francisco Torreira, Franc Grootjen, Louis Vuurpijl, and Larry Caruthers.
 
 And of course my friends and acquaintances that supported me throughout the process.

diff --git a/back/summary.tex b/back/summary.tex
index 26e7796..91ee7b7 100644 (file)
--- a/back/summary.tex
+++ b/back/summary.tex
@@ -13,19 +13,18 @@ The number of computers around us is growing exponentially, compounding the comp
 Many of these computers are \emph{edge devices} operating in \gls{IOT} systems.
 Within these orchestrations of computers, they interact with the environment using sensors and actuators.
 Edge devices often use low-cost microcontrollers designed for embedded applications.
 Many of these computers are \emph{edge devices} operating in \gls{IOT} systems.
 Within these orchestrations of computers, they interact with the environment using sensors and actuators.
 Edge devices often use low-cost microcontrollers designed for embedded applications.

-They have little memory, unhurried processors, and are slow in communication.
-Yet they are small and energy efficient.
+They have little memory, unhurried processors, and are slow in communication but are also small and energy efficient.

 Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature.
 Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature.

-This is impeded more so by semantic friction that arises through different hardware and software characteristics between tiers.
+The complexity is increased further by semantic friction that arises through different hardware and software characteristics between tiers.

 
 A solution is found in \gls{TOP}.
 %A solution is found in the declarative programming paradigm \gls{TOP}.%, a declarative programming paradigm.
 In \gls{TOP}, the main building blocks are tasks, an abstract representation of work.
 During execution, the current value of the task is observable, and other tasks can act upon it.
 
 A solution is found in \gls{TOP}.
 %A solution is found in the declarative programming paradigm \gls{TOP}.%, a declarative programming paradigm.
 In \gls{TOP}, the main building blocks are tasks, an abstract representation of work.
 During execution, the current value of the task is observable, and other tasks can act upon it.

-Collaboration patterns can be modelled by combinding and transforming tasks into compound tasks.
-From this declarative description of the work, a ready-for-work computer system is generated that guides the user in doing the work.
+Collaboration patterns can be modelled by combining and transforming tasks into compound tasks.
+From this declarative description of the work, a ready-for-work computer system is generated that guides all operators in doing the work.

 An example of a \gls{TOP} system is \gls{ITASK}, a language which describes interactive web applications.
 An example of a \gls{TOP} system is \gls{ITASK}, a language which describes interactive web applications.

-Programming edge devices would benefit from \gls{TOP} as well.
+Programming edge devices benefits from \gls{TOP} as well.

 However, it is not straightforward to run \gls{TOP} systems on resource-constrained edge devices.
 
 This dissertation demonstrates how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
 However, it is not straightforward to run \gls{TOP} systems on resource-constrained edge devices.
 
 This dissertation demonstrates how to orchestrate complete \gls{IOT} systems using \gls{TOP}.


@@ -39,8 +38,7 @@ For a device to be used in an \gls{MTASK} system, it must to be programmed once
 This \gls{OS} executes tasks in an energy-efficient way and automates all communications and data sharing.
 All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities.
 When using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems are programmed tierlessly from a single source, language, paradigm, high abstraction level, and type system.
 This \gls{OS} executes tasks in an energy-efficient way and automates all communications and data sharing.
 All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities.
 When using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems are programmed tierlessly from a single source, language, paradigm, high abstraction level, and type system.

-The dissertation concludes with a comparison between tierless programming, in particular in \gls{MTASK}, and traditional tiered programming.
-It demonstrates that many problems such as semantic friction, maintainability, robustness, and interoperation safety are mitigated when using tierless programming.
+Many problems such as semantic friction; maintainability and robustness issues; and interoperation safety are mitigated when using tierless programming.

 %This is a summary of 350--400 words.
 %\end{center}
 \end{document}
 %This is a summary of 350--400 words.
 %\end{center}
 \end{document}

diff --git a/concl/concl.tex b/concl/concl.tex
index c454398..cfbb92a 100644 (file)
--- a/concl/concl.tex
+++ b/concl/concl.tex
@@ -20,7 +20,7 @@ The complexity mainly arises from the fact that each layer of the system is buil
 This generates a lot of semantic friction.
 Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
 This generates a lot of semantic friction.
 Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.

-However, edge devices are often too computationally restricted to be able to run traditional \gls{TOP} systems.
+However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}.

 This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
 It specifically fills in the knowledge gap for edge devices.
 The contributions are split up into three episodes.
 This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
 It specifically fills in the knowledge gap for edge devices.
 The contributions are split up into three episodes.


@@ -38,7 +38,7 @@ The scaffolding is generated using template metaprogramming and quasiquotation i
 
 \Cref{prt:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities.
 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
 
 \Cref{prt:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities.
 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.

-The system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
+The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.

 In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
 The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
 Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements.
 In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
 The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
 Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements.


@@ -54,11 +54,12 @@ The comparison demonstrates that programming such complex systems using a tierle
 Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
 
 However, it is not a silver bullet.
 Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
 
 However, it is not a silver bullet.

+However, it has some disadvantages as well.

 Tierless languages are novel, and hence lacking tooling and community support.
 They contain many high-level tierless abstractions that the programmer has to master.
 The low-level specific semantics of the final application may become more difficult to destill from the specification.
 Finally, the system is quite monolithic.
 Tierless languages are novel, and hence lacking tooling and community support.
 They contain many high-level tierless abstractions that the programmer has to master.
 The low-level specific semantics of the final application may become more difficult to destill from the specification.
 Finally, the system is quite monolithic.

-Changing components within the system is easy if it already exists in the host language.
+Changing components within the system is easy if it already is supported in the \gls{EDSL}.

 Adding new components to the system requires the programmer to add it to all complex components of the languages such as the compiler, and \gls{RTS}.
 
 \input{subfilepostamble}
 Adding new components to the system requires the programmer to add it to all complex components of the languages such as the compiler, and \gls{RTS}.
 
 \input{subfilepostamble}

diff --git a/glossaries.tex b/glossaries.tex
index fc8ffe7..edae456 100644 (file)
--- a/glossaries.tex
+++ b/glossaries.tex
@@ -71,7 +71,7 @@
 }
 \newglossaryentry{MTASK}{%
        name=mTask,
 }
 \newglossaryentry{MTASK}{%
        name=mTask,

-       description={- a \glsxtrshort{TOP} \glsxtrshort{EDSL} for microcontrollers integrated with the \gls{ITASK} system},
+       description={- a \glsxtrshort{TOP} \glsxtrshort{EDSL} for edge devices integrated with the \gls{ITASK} system},

 }
 \newglossaryentry{ITASK}{%
        name=iTask,
 }
 \newglossaryentry{ITASK}{%
        name=iTask,

diff --git a/top/finale.tex b/top/finale.tex
index 34e0131..8738588 100644 (file)
--- a/top/finale.tex
+++ b/top/finale.tex
@@ -9,7 +9,7 @@
 \chapter{Finale}%
 \label{chp:finale}
 \begin{chapterabstract}
 \chapter{Finale}%
 \label{chp:finale}
 \begin{chapterabstract}

-       \noindent This chapter wraps up the monograph by means of:
+       This chapter wraps up the monograph by means of:

        \begin{itemize}
                \item a conclusion;
                \item an outlook on future work;
        \begin{itemize}
                \item a conclusion;
                \item an outlook on future work;


@@ -19,26 +19,27 @@
 \end{chapterabstract}
 
 \section{Finale}
 \end{chapterabstract}
 
 \section{Finale}

-Traditionally, \gls{IOT} have been programmed using layered architectures.
+Traditionally, \gls{IOT} has been programmed using layered, or tiered, architectures.

 Every layer has its own software and hardware characteristics, resulting in semantic friction.
 Every layer has its own software and hardware characteristics, resulting in semantic friction.

-\Gls{TOP} is a declarative programming paradigm designed for specifying multi-tiered interactive systems.
+\Gls{TOP} is a declarative programming paradigm designed to describe multi-tiered interactive systems.

 However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices.
 
 The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices.
 However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices.
 
 The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices.

-It is a full-fledged \gls{TOP} language hosted in a tiny functional programming language containing basic tasks, task combinators, support for sensors and actuators, and interrupts.
-It is integrated seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications.
+It is a full-fledged \gls{TOP} language hosted in a tiny \gls{FP} language.
+Besides the usual \gls{FP} constructs, it contains basic tasks, task combinators, support for sensors and actuators, and interrupts.
+It integrates seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications.

 Hence, all layers of an \gls{IOT} system can be programmed from a single declarative specification.
 Hence, all layers of an \gls{IOT} system can be programmed from a single declarative specification.

-\Gls{ITASK} abstracts away from the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
-The engine of \gls{MTASK} abstracts away of all technicalities such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
+In \gls{ITASK}, abstraction are available for the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
+The engine of \gls{MTASK} abstracts away of all technicalities specific to edge devices such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.

 
 

-The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.

 Any device equipped with the \gls{MTASK} \gls{RTS} can be used in the system and dynamically receive tasks for execution.
 This domain-specific \gls{OS} only needs to be programmed once, hence saving precious write cycles on the program memory.
 Any device equipped with the \gls{MTASK} \gls{RTS} can be used in the system and dynamically receive tasks for execution.
 This domain-specific \gls{OS} only needs to be programmed once, hence saving precious write cycles on the program memory.

+The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.

 Once connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.
 Once connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.

-The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the work that needs to be done.
+The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the current work requirements.

 When lifted, other tasks in the system can interact with the task through the usual means.
 When lifted, other tasks in the system can interact with the task through the usual means.

-Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system.
-\todo[inline]{Uitbreiden}
+Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system irrespective of task relations.
+\todo{Uit\-brei\-den?}

 
 \section{Future work}
 \todo[inline]{De grens tussen future en related work is soms vaag maar ik heb het zo goed als mogelijk proberen te scheiden. Mis ik hier nog iets?}
 
 \section{Future work}
 \todo[inline]{De grens tussen future en related work is soms vaag maar ik heb het zo goed als mogelijk proberen te scheiden. Mis ik hier nog iets?}

diff --git a/top/int.tex b/top/int.tex
index 4b9c3c1..1ef5860 100644 (file)
--- a/top/int.tex
+++ b/top/int.tex
@@ -145,6 +145,8 @@ liftmTask task (MTDevice dev sdsupdates channels)
                        -|| watchSharesUpstream mrefs channels tid)
 \end{lstClean}
 
                        -|| watchSharesUpstream mrefs channels tid)
 \end{lstClean}
 

+\todo{dis\-cuss pre\-loading}
+

 \section{Lifting \texorpdfstring{\gls{ITASK}}{iTask} \texorpdfstring{\glsxtrlongpl{SDS}}{shared data sources}}\label{sec:liftsds}
 Lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS} is something that mostly happens at the compiler level using the \cleaninline{liftsds} function (see \cref{lst:mtask_itasksds}).
 \Glspl{SDS} in \gls{MTASK} must always have an initial value.
 \section{Lifting \texorpdfstring{\gls{ITASK}}{iTask} \texorpdfstring{\glsxtrlongpl{SDS}}{shared data sources}}\label{sec:liftsds}
 Lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS} is something that mostly happens at the compiler level using the \cleaninline{liftsds} function (see \cref{lst:mtask_itasksds}).
 \Glspl{SDS} in \gls{MTASK} must always have an initial value.