+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.
+
+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.
+
+\subsection{\texorpdfstring{\Glsxtrlong{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.
+
+\subsection{Scheduling}
+The scheduling in \gls{MTASK} works quite well but it is not real time.
+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.
+\Citet{belwal_variable_2013} use \gls{PFRP} with \gls{DVFS} to reduce the energy consumption.
+It would be interesting to investigate the possibilities for \gls{DVFS} in \gls{MTASK} and \gls{TOP} in general.