bib fix

diff --git a/top/finale.tex b/top/finale.tex
index 6b002bb..7d90b58 100644 (file)
--- a/top/finale.tex
+++ b/top/finale.tex
@@ -94,7 +94,7 @@ Regular preemptive multithreading is too memory intensive for smaller microcontr
 Manual interleaving of imperative code can be automated to certain extents.
 Solutions often require an \gls{RTOS}, have a high memory requirement, do not support local variables, no thread-safe shared memory, no composition or no events as described in \cref{tbl:multithreadingcompare}.
 This table extends a comparison table with various solutions to multitasking to \gls{MTASK} in the relevant categories.
-\todo[inline]{Uitleg over de talen geven}
+%\todo[inline]{Uitleg over de talen geven}
 
 \begin{table}
        \begin{threeparttable}
@@ -157,7 +157,7 @@ These \gls{IO} functions can then be used as signals and combined as in any \gls
 Due to the compilation to \gls{C} it is possible to run emfrp programs on tiny computers.
 However, in contrast to in \gls{MTASK}, the tasks are not interpreted and there is no automated communication with a server.
 
-Other examples are CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{10.1145/3281366.3281370}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, Haski \citep{valliappan_towards_2020}, arduino-copilot \citep{hess_arduino-copilot_2020}.
+Other examples are CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{shibanai_distributed_2018}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, Haski \citep{valliappan_towards_2020}, arduino-copilot \citep{hess_arduino-copilot_2020}.
 
 \subsection{Task-oriented programming}\label{sec:related_top}
 \Gls{TOP} as a paradigm has proven to be effective for implementing distributed, multi-user applications in many domains.

diff --git a/tvt/tvt.tex b/tvt/tvt.tex
index 3854bdd..cffffdc 100644 (file)
--- a/tvt/tvt.tex
+++ b/tvt/tvt.tex
@@ -185,7 +185,7 @@ and Ivory \citep{elliott_guilt_2015} are imperative \glspl{DSL} embedded in a fu
 
 \subsubsection{Functional reactive programming}
 \Gls{FRP} is a declarative paradigm often used for implementing the perception layer of an \gls{IOT} stack.
-Examples include mfrp \citep{sawada_emfrp:_2016}, CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{10.1145/3281366.3281370}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, and Haski \citep{valliappan_towards_2020}.
+Examples include mfrp \citep{sawada_emfrp:_2016}, CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{shibanai_distributed_2018}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, and Haski \citep{valliappan_towards_2020}.
 None of these languages are tierless \gls{IOT} languages as they have no automatic integration with the server.
 
 Potato goes beyond other \gls{FRP} languages to provide a tierless \gls{FRP} \gls{IOT} language for resource rich sensor nodes \citep{troyer_building_2018}. It does so using the Erlang programming language and sophisticated virtual machine. 
@@ -1173,7 +1173,7 @@ Our empirical results are consistent with the benefits of tierless languages lis
 
 This study is based on a specific pair of tierless \gls{IOT} languages, and the \gls{CLEAN} language frameworks represent a specific set of tierless language design decisions. Many alternative tierless \gls{IOT} language designs are possible, and some are outlined in \cref{sec_t4t:characteristics}. Crucially the limitations of the tierless \gls{CLEAN} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general. 
 
-This study has explored some, but not all, of the potential benefits of tierless languages for \gls{IOT} systems. An \gls{IOT} system specified as a single tierless program is amenable to a host of programming language technologies. For example, if the language has a formal semantics, as Links, Hop and \gls{CLEAN} tasks do \citep{cooper2006links,serrano2006hop,plasmeijer_task-oriented_2012}, it is possible to prove properties of the system, e.g.\ \citep{Steenvoorden2019tophat}. As another example program analyses can be applied, and \cref{sec_t4t:characteristics} and \citep{weisenburger2020survey} outline some of the analyses could be, and in some cases have been, used to improve \gls{IOT} systems. Examples include automatic tier splitting \citep{10.1145/2661136.2661146}, and controlling information flow to enhance security \citep{valliappan_towards_2020}. 
+This study has explored some, but not all, of the potential benefits of tierless languages for \gls{IOT} systems. An \gls{IOT} system specified as a single tierless program is amenable to a host of programming language technologies. For example, if the language has a formal semantics, as Links, Hop and \gls{CLEAN} tasks do \citep{cooper2006links,serrano2006hop,plasmeijer_task-oriented_2012}, it is possible to prove properties of the system, e.g.\ \citep{steenvoorden_tophat_2019}. As another example program analyses can be applied, and \cref{sec_t4t:characteristics} and \citep{weisenburger2020survey} outline some of the analyses could be, and in some cases have been, used to improve \gls{IOT} systems. Examples include automatic tier splitting \citep{10.1145/2661136.2661146}, and controlling information flow to enhance security \citep{valliappan_towards_2020}. 
 
 While offering real benefits for \gls{IOT} systems development, tierless languages also raise some challenges. Programmers must master new tierless programming abstractions, and the semantics of these automatic multi-tier behaviours are necessarily relatively complex. In the \gls{CLEAN} context this entails becoming proficient with the \gls{ITASK} and \gls{MTASK} \glspl{DSL}. Moreover, specifying a behaviour that is not already provided by the tierless language requires either a workaround, or extending a \gls{DSL}. However, implementing the relatively simple smart campus application required no such adaption. Finally, tierless \gls{IOT} technology is very new, and both tool and community support have yet to mature.