Besides the usual \gls{FP} constructs, it contains basic tasks, task combinators, support for sensors and actuators, and interrupts.
It integrates seamlessly into \gls{ITASK}, a \gls{TOP} system for interactive web applications.
In \gls{ITASK}, abstractions are available for the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
-The \gls{MTASK} system abstracts away of all technicalities specific to edge devices such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
-When \gls{MTASK} is used together with \gls{MTASK}, all layers of the \gls{IOT} application are programmed from a single declarative specification.
+The \gls{MTASK} system abstracts away all technicalities specific to edge devices such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
+When \gls{MTASK} is used together with \gls{ITASK}, all layers of the \gls{IOT} application are programmed from a single declarative specification.\todo{is this demonstrated anywhere in the thesis?
+Could you point to an example (perhaps in a paper not in the thesis)}
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 is uploaded once, hence saving precious write cycles on the program memory.
All of these languages, except the Lisp dialect uLisp (see \cref{sec:related_fp}), are imperative and do not support multitasking out of the box.
They lay pretty hefty constraints on the memory and as a result do not work on smaller microcontrollers.
Another interpretation solution for the tiniest devices is Firmata, a protocol for remotely controlling the microcontroller using a server as the interpreter host \citep{steiner_firmata:_2009}.
-\citet{grebe_haskino:_2016} wrapped this in a remote monad for integration with \gls{HASKELL} that allowed imperative code to be interpreted on the microprocessors.
+\citet{decker_tierless_2015} describes a FlowLog \citep{nelson_tierless_2014} extension to incorporate \gls{IOT} devices into their tierless sytem for software-defined network controllers in a similar way as firmata.
+\citet{grebe_haskino:_2016} wrapped Firmata in a remote monad for integration with \gls{HASKELL} that allowed imperative code to be interpreted on the microprocessors.
Later this system was extended to support multithreading as well, stepping away from Firmata as the basis and using their own \gls{RTS} \citep{grebe_threading_2019}.
-It differs from our approach because it is required to mark continuation points by hand and there is no automatic safe data communication.
+Both differ from our approach because it is required to mark continuation points by hand and there is no automatic safe data communication.
\Citet{baccelli_reprogramming_2018} provide a single language \gls{IOT} system based on the RIOT \gls{OS} that allows runtime deployment of code snippets called containers.
Both client and server are written in JavaScript.
\subsection{DSLs}\label{sec:related_dsl}
Many \glspl{DSL} provide higher-level programming abstractions for microcontrollers, for example providing strong typing or memory safety.
Examples of this are Copilot \citep{hess_arduino-copilot_2020} and Ivory \citep{elliott_guilt_2015}.
-Both imperative \glspl{DSL} embedded in a functional language that compile to \ccpp{}.
+Both are imperative \glspl{DSL} embedded in a functional language that compiles to \ccpp{}.
\subsection{Functional programming}\label{sec:related_fp}
\Citet{haenisch_case_2016} showed that there are major benefits to using functional languages on edge devices.
\Gls{TOP} allows for more complex collaboration patterns than \gls{FRP} \citep{wang_maintaining_2018}.
Consequently, \gls{TOP} is unable to provide strong guarantees on memory usage, something \gls{FRP} is capable of.
For example, arrowised \gls{FRP} can give guarantees on upper memory bounds \citep{nilsson_functional_2002}.
-The way \gls{FRP}, and for that matter \gls{TOP}, systems are programmed stays close to the design when the domain matches suits the paradigm.
+The way \gls{FRP}, and for that matter \gls{TOP}, systems are programmed stays close to the design when the domain matches the paradigm.
The \gls{IOT} domain seems to suit this style of programming very well in just the device layer but also for entire \gls{IOT} systems.
For example, Potato is an \gls{FRP} language for building entire \gls{IOT} systems using powerful devices such as the Raspberry Pi leveraging the Erlang \gls{VM} \citep{troyer_building_2018}.
It would be interesting to see how and whether (parts of) \gls{TOP} programs or the functionality of the \gls{MTASK} \gls{OS} could be translated to \gls{FPGA} specifications.
\subsection{Formal semantics}
-Semantics allow reasoning about the language and programs in order do (symbolic) simulation, termination checking, task equivalence, or otherwise.
+Semantics allow reasoning about the language and programs in order to do (symbolic) simulation, termination checking, task equivalence, or otherwise.
For \gls{ITASK} there have been two attempts to formally specify the language.
First \citet{koopman_executable_2011} defined a semantics used for property based testing based on a minimal version of \gls{ITASK}.
Then \citet{plasmeijer_task-oriented_2012} formalised \gls{ITASK} by providing an executable semantics for the language.
The \gls{ITASK} language is designed exactly the opposite.
From just a few super combinators, all other combinators are derived.
However, this approach requires a very powerful host language in which task combinators can be defined in terms of the host language.
-It could be fruitful to investigate which workflows cannot be specified with the limited set of combinators available in \gls{MTASK}.
-Furthermore, it is unclear whether all derived combinators from \gls{ITASK} can be expressed in terms of \gls{MTASK} combinators.
+It would be fruitful to investigate which workflows cannot be specified with the limited set of combinators available in \gls{MTASK}.
\Citet{van_der_aalst_workflow_2003} defines a benchmark set of workflow patterns.
It is interesting to see which patterns can already be implemented with just \gls{MTASK}, which require a round-trip with the server, and what additional combinators would be needed.
If the editor produces correct \gls{MTASK} code by construction, much of the problems could be avoided.
In the same respect, as \gls{MTASK} is a tagless-final \gls{EDSL} and uses \gls{HOAS}, the error messages are complex and larded with host language features.
Much research has gone into simplifying these error messages by translating them to the \gls{DSL} domain, see for example the work by \citep{serrano_type_2018}.
-De Roos briefly investigated these methods in their research internship.
+De Roos briefly investigated these methods in their research internship.\todo{cite? but how}
A future directions could be to extend these findings and apply more \gls{EDSL} error message techniques on \gls{MTASK} as well.
\subsection{Language features}
For example, the pin mode could be made a type parameter of the \gls{GPIO} pins, or interrupt handling could be made safer by incorporating the capabilities of the devices in order to reduce run-time errors.
\subsection{Scheduling}
-The scheduling in \gls{MTASK} works quite well, but it is not real time.
+The scheduling in \gls{MTASK} works quite well, but it is not real time.\todo{mention evaluation}
There is a variant of \gls{FRP} called \gls{PFRP} that allows for real-time operation \citep{belwal_variable_2013}.
Furthermore, an alternative to reducing the energy consumption by going to sleep is stepping down the processor frequency.
So called \gls{DVFS} is a scheduling technique that slows down the processor in order to reach the goals as late as possible, reducing the power consumption.
This section provides an exhaustive overview of the work on \gls{MTASK} and its predecessors.
\subsection{Generating \ccpp{} code}
-A first throw at a class-based shallowly \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}.
+A first throw at a class-based shallow \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}.
The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect.
A \gls{CPP} code generation interpretation was available together with an \gls{ITASK} simulation interpretation.
There was no support for tasks nor functions.
However, this version used a simplified version of \gls{MTASK} without functions.
This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
It was shown by \citet{amazonas_cabral_de_andrade_developing_2018} that it was possible to build real-life \gls{IOT} systems with this integration.
+They did so by creating a functioning prototype of a smart home application.
Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2023}.
\subsection{Transition to Task-oriented programming}
\citet{van_der_veen_mutable_2020} did preliminary work on a green computing analysis, built a simulator, and explored the possibilities for adding bounded datatypes; de Roos explored beautifying error messages; \citet{de_boer_secure_2020} investigated the possibilities for secure communication channels; \citeauthor{crooijmans_reducing_2021} \citeyearpar{crooijmans_reducing_2021,crooijmans_reducing_2022} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling; and \citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK}.
-\subsection{Using mTask in practise}
+\subsection{Using mTask in practice}
Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
An existing smart campus application was developed using \gls{MTASK} and quantitatively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2023} (see \cref{chp:smart_campus}).
repositories / phd-thesis.git / blobdiff