+The \gls{MTASK} system is a proof-of-concept system, though fully functioning, for integrating \gls{IOT} edge devices in \gls{TOP}.
+In conjunction with \gls{ITASK}, it is possible to program all layers of the \gls{IOT} from a single declarative specification.
+The \gls{ITASK} system is used to program the top layers of an \gls{IOT} system, providing the server and the web \gls{UI}.
+Then, \gls{MTASK} can be used to integrate edge devices.
+Tasks for edge devices are written in the \gls{MTASK} \gls{DSL} and can be integrated in \gls{ITASK} using only a few functions.
+\todo{extend}
+
+Deep embedding.
+
+\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?}
+There are many ways of extending the research on the \gls{MTASK} system that also concerns \gls{TOP} for resource constrained devices in general.
+Some obvious routes would be to add features, support more platforms,
+
+\todo{security}
+
+\subsection{Advanced edge devices techniques}
+Edge devices may produce a lot of data and it is not always effective to send this data to the server for processing.
+Leaving the produced data and computations on the edge device is called \emph{edge computing} \citep{shi_edge_2016}.
+The \gls{MTASK} exhibits many properties of edge computing because it is possible to run entire workflows on the device.
+However, it would be interesting to see how far this can be extended.
+The \gls{MTASK} language is a high-level \gls{DSL} so it would be obvious to introduce abstractions for edge computations.
+For example, add \gls{TOP} support for machine learning on the edge device using TinyML \citep{sanchez-iborra_tinyml-enabled_2020}.
+
+Another recent advance in \gls{IOT} programming is battery-less or even battery-free computing.
+Instead of equipping the edge device with a battery, a capacitor is used in conjunction with some energy harvesting systems such as a solar panel.
+With the use of intermittent computing, resuming the computation after a, possibly unexpected, power loss, operation can still be achieved \citep{hester_batteries_2019}.
+After a reset, the program state is resumed from a checkpoint that was stored in some non-volatile memory.
+Many intermittent computing solutions rely on annotations from the programmer to divide the program into atomic blocks, sometimes called \emph{tasks} as well.
+These blocks are marked as such because in the case of an reset of the system, the work must be done again.
+Examples of such blocks are \gls{I2C} transmissions or calculations that rely on recent sensor data.
+In \gls{MTASK}, all work expressed by tasks is already split up in atomic pieces of work.
+Furthermore, creating checkpoints should be fairly straightforward as \gls{MTASK} tasks do not rely on any global state---all information required to execute a task is stored in the task tree.
+It would be interesting to see what \gls{TOP} abstraction could be useful for intermittent computing and what solutions are required to make this work.
+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.
+It would be interesting to investigate the possibilities for \gls{DVFS} in \gls{MTASK}.
+
+Mesh networks allow for communication not only to-and-fro the device and server but also between devices.
+The \gls{ITASK} system already contains primitives for distributed operation.
+For example, it is possible to run tasks or share data with \glspl{SDS} on a different machine.
+It would be interesting to investigate how this networking technique can be utilised in \gls{MTASK}.
+
+Finally, \glspl{FPGA} have been becoming cheaper and faster recently, allowing for purely functional code to be translated to \glspl{FPGA} code efficiently \citep{baaij_digital_2015}.
+It would be interested 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.
+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.
+Both semantics are not suitable for formal reasoning due to the complexity.
+Later, \citet{steenvoorden_tophat_2019} created \gls{TOPHAT}, a \gls{TOP} language with a complete formal specification with similar features to \gls{MTASK} \citep{steenvoorden_tophat_2019}.
+\Citet{antonova_mtask_2022} compared parts of \gls{MTASK} to the semantics of \gls{TOPHAT} semantics and created a preliminary semantics for a subset of \gls{MTASK}.
+Future research into extending the formal semantics of \gls{MTASK} is useful to give more guarantees on \gls{MTASK} programs.
+Maybe this opens the door to real-time operation as well.
+
+\subsection{\texorpdfstring{\Gls{TOP}}{Task-oriented programming}}
+In order to keep the resource constraints low, the \gls{MTASK} language contains only a minimal set of simple task combinators.
+From these simple combinators, complex collaboration patterns can be described.
+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 would 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.
+\Citet{van_der_aalst_workflow_2003} defines a benchmark set of workflow patterns.
+It would be interesting to see which patterns can be implemented with \gls{MTASK}, and what additional combinators would be needed.
+Moreover, editors are a crucial part of \gls{TOP}.
+In \gls{MTASK}, sensors can be seen as read-only shared editors that are updated by the system.
+It would be interesting to investigate how actual interactive editors would fit in \gls{MTASK}.
+For example, many smartwatches contain touch sensitive screens that could be used to interact with the user in this way.
+
+\Glspl{SDS} in \gls{ITASK} have a rich set of combinators to transform and combine the \glspl{SDS} into new \gls{SDS}.
+In \gls{MTASK}, \glspl{SDS} are just typed global variables that may or may not proxy an \gls{ITASK} \gls{SDS}.
+It would be interesting to port the \gls{SDS} combinators to \gls{MTASK} as well, allowing them to be transformed and combined also.
+
+\subsection{Usability}
+The promise of \glspl{DSL} has often been that a domain expert could program with little technical knowledge of the host programming language.
+Some even propose that a \gls{DSL} is a \gls{UI} for domain experts to computation platforms \citep{management_association_evaluating_2014}.
+In practise this is not always the case due to crippling syntax and convoluted error messages.
+Recent approaches in interactive editors for programming language source code such as dynamic editors \citep{koopman_dynamic_2021} or typed tree editors such as Hazelnut \citep{omar_hazelnut_2017} could prove useful for supporting the \gls{DSL} programmer in using \gls{MTASK}.
+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 \citep{serrano_type_2018}.
+A future directions could be to apply the \gls{EDSL} error message techniques on \gls{MTASK} as well.
+
+The serialisation and deserialisation of data types is automated both on the server and the \gls{MTASK} device using generic programming.
+Using the structural information of the data type, the code responsible for the functionality is automatically generated.
+Peripherals are not yet fully integrated in such a way.
+When a peripheral is added, the programmer has to define the correct byte code, implement the instructions in the interpreter, add task tree nodes, and implement them in the rewrite system.
+It would be interesting to investigate whether this can be automated or centralised in a way.