upadtes
[phd-thesis.git] / tvt / tvt.tex
index abc5041..e622e86 100644 (file)
@@ -322,7 +322,7 @@ readTempTask =
                \includegraphics[width=\textwidth]{simpleTempSensor}
                \caption{Deployment diagram.}
        \end{subfigure}
-       \caption{\Gls{ITASK} SimpleTempSensor.}%
+       \caption{SimpleTempSensor written in \gls{ITASK}.}%
        \label{fig_t4t:itaskTempSimple}
 \end{figure}
 
@@ -489,7 +489,7 @@ there is no \gls{OS} to start the remote task, the code of the task is too big t
 The \gls{MTASK} \gls{EDSL} is designed to bridge this gap: \gls{MTASK} tasks can be communicated from the server to the sensor node, to execute within the limitations of a typical microcontroller, while providing programming abstractions that are consistent with \gls{ITASK}.
 
 Like \gls{ITASK}, \gls{MTASK} is task oriented, e.g.\ there are primitive tasks that produce intermediate values, a restricted set of task combinators to compose the tasks, and (recursive) functions to construct tasks.
-\Gls{MTASK} tasks communicate using task values or \glspl{SDS} that may be local or remote, and may be shared by some \gls{ITASK} tasks.
+Tasks in \gls{MTASK} communicate using task values or \glspl{SDS} that may be local or remote, and may be shared by some \gls{ITASK} tasks.
 
 Apart from the \gls{EDSL}, the \gls{MTASK} system contains a featherlight domain-specific \emph{operating system} running on the microcontroller.
 This \gls{OS} task scheduler receives the byte code generated from one or more \gls{MTASK} programs and interleaves the execution of those tasks. The \gls{OS} also manages \gls{SDS} updates and the passing of task results.
@@ -666,7 +666,7 @@ The main goal of the \gls{UOG} smart campus project is to provide a testbed for
 
        \item scale to no more than 10 sensors per sensor node and investigate further sensor options like measuring sound levels,
 
-       \item have access to communication channels like WiFi, Bluetooth and even wired networks.
+       \item have access to communication channels like \gls{WIFI}, Bluetooth and even wired networks.
 
        \item have a centralised database server,
 
@@ -1111,7 +1111,7 @@ Even in low level languages some language features are disabled by default when
 
 Here we investigate the restrictions imposed by resource-constrained sensor nodes on \gls{MTASK}, in comparison with \gls{ITASK}. While \gls{ITASK} and \gls{MTASK} are by design superficially similar languages, to execute on resource-constrained sensor nodes \gls{MTASK} tasks are more restricted, and have a different semantics.
 
-\Gls{MTASK} programs do not support user defined higher order functions, the only higher order functions available are the predefined \gls{MTASK} combinators.
+Programs in \gls{MTASK} do not support user defined higher order functions, the only higher order functions available are the predefined \gls{MTASK} combinators.
 Programmers can, however, use any construct of the \gls{CLEAN} host language to construct an \gls{MTASK} program, including higher order functions and arbitrary data types. For example folding an \gls{MTASK} combinator over a list of tasks.
 The only restriction is that any higher order function must be macro expanded to a first order \gls{MTASK} program before being compiled to byte code.
 As an example in \cref{lst_t4t:mtasktemp} we use \cleaninline{temperature dht >>~.} \cleaninline{setSds localSds} instead of \cleaninline{temperature dht >>~.} \cleaninline{\\temp -> setSds localSds temp}.
@@ -1121,9 +1121,9 @@ In contrast to \gls{ITASK}, \gls{MTASK} programs have no user defined or recursi
 Due to the language being shallowly embedded, pattern matching and field selection on user defined types is not readily available and thus needs to be built into the language by hand.
 Alleviating this limitation remains future work.
 
-\Gls{MTASK} programs mainly use strict rather than lazy evaluation to minimise the requirement for a variable size heap. This has no significant impact for the \gls{MTASK} programs we have developed here, nor in other \gls{IOT} applications we have engineered.
+Programs in \gls{MTASK} mainly use strict rather than lazy evaluation to minimise the requirement for a variable size heap. This has no significant impact for the \gls{MTASK} programs we have developed here, nor in other \gls{IOT} applications we have engineered.
 
-\Gls{MTASK} abstractions are less easily extended than \gls{ITASK}. For example \gls{ITASK} can be extended with a new combinator that composes a specific set of tasks for some application.
+Abstractions in \gls{MTASK} are less easily extended than \gls{ITASK}. For example \gls{ITASK} can be extended with a new combinator that composes a specific set of tasks for some application.
 Without higher order functions the equivalent combinator can often not be expressed in \gls{MTASK}, and adding it to \gls{MTASK} requires extending the \gls{DSL} rather than writing a new definition in it.
 On the other hand, it is possible to outsource this logic to the \gls{ITASK} program as \gls{MTASK} and \gls{ITASK} tasks are so tightly integrated.