+Another recent advance in \gls{IOT} edge device 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 energy harvesting systems such as a solar panel.
+After a reset, the program state is resumed from a checkpoint that was stored in some non-volatile memory.
+This technique is called intermittent computing \citep{hester_batteries_2019}.
+Many intermittent computing solutions rely on annotations from the programmer to divide the program into atomic blocks, sometimes called tasks as well.
+These blocks are marked as such, because in the case of a 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, i.e.\ the work is a side effect of rewriting.
+Furthermore, creating checkpoints is 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 is interesting to see what \gls{TOP} abstractions are useful to support intermittent computing properly and what solutions are required to make it 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 different machines.
+It is interesting to investigate how this networking technique can be utilised in \gls{MTASK}.
+
+\Glspl{FPGA} are highly customisable integrated chips consisting of programmable gates.
+Promising research has gone into translating purely functional code to \gls{FPGA} configurations \citep{baaij_digital_2015}.
+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 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.
+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{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 expressed.
+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}.
+\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.
+
+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 is 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.
+Alternatively, sufficiently powerful edge devices can probably run simple web interfaces as well.
+
+\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 typed global variables that may or may not proxy an \gls{ITASK} \gls{SDS}.
+It could 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 the work by \citep{serrano_type_2018}.
+\Citet{de_roos_2020} briefly investigated these methods in their research internship.
+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}
+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.
+
+More elaborate features in the type systems of modern functional programming languages allow for more type safety.
+The \gls{MTASK} language relies a lot on these features such as (multi-parameter) type classes and existential data types with class constraints.
+However, it should be possible to make abstractions over an increasing number of features to make it safer still.
+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.
+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 is interesting to investigate the possibilities for \gls{DVFS} in \gls{MTASK} and \gls{TOP} in general.
+
+\section{History of mTask}