From 6031ff9bdade1ff5045c29fbe501ede5d927576c Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Wed, 22 Feb 2023 14:14:41 +0100 Subject: [PATCH] bib fix --- top/finale.tex | 4 ++-- tvt/tvt.tex | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/top/finale.tex b/top/finale.tex index 6b002bb..7d90b58 100644 --- 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 --- 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. -- 2.20.1