Here we investigate the restrictions imposed by resource-constrained sensor nodes on \gls{MTASK}, in comparison with \gls{ITASK}. While \gls{ITASK} and \gls{MTASK} are by design superficially similar languages, to execute on resource-constrained sensor nodes \gls{MTASK} tasks are more restricted, and have a different semantics.
\Gls{MTASK} programs do not support user defined higher order functions, the only higher order functions available are the predefined \gls{MTASK} combinators.
Programmers can, however, use any construct of the \gls{CLEAN} host language to construct an \gls{MTASK} program, including higher order functions and arbitrary data types. For example folding an \gls{MTASK} combinator over a list of tasks.
The only restriction is that any higher order function must be macro expanded to a first order \gls{MTASK} program before being compiled to byte code.
Here we investigate the restrictions imposed by resource-constrained sensor nodes on \gls{MTASK}, in comparison with \gls{ITASK}. While \gls{ITASK} and \gls{MTASK} are by design superficially similar languages, to execute on resource-constrained sensor nodes \gls{MTASK} tasks are more restricted, and have a different semantics.
\Gls{MTASK} programs do not support user defined higher order functions, the only higher order functions available are the predefined \gls{MTASK} combinators.
Programmers can, however, use any construct of the \gls{CLEAN} host language to construct an \gls{MTASK} program, including higher order functions and arbitrary data types. For example folding an \gls{MTASK} combinator over a list of tasks.
The only restriction is that any higher order function must be macro expanded to a first order \gls{MTASK} program before being compiled to byte code.