Similar research has been conducted on the subject.
For example, microcontrollers such as the \gls{Arduino} can be remotely
controlled very directly using the
\gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the
Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed:
23-May-2017].}. This protocol is designed to allow control of the peripherals
--- such as sensors and actuators --- directly through commands sent via a
communication channel such as a serial port.  This allows very fine grained
control but with the cost of excessive communication overhead since no code is
executed on the device itself, only the peripherals are queried. A
\gls{Haskell} implementation of the protocol is also
available\footnote{``hArduino by LeventErkok.'' (
\url{https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. The
hardware requirements for running a \gls{Firmata} client are very low.
However, the communication requirements are high and therefore it is not
suitable for \gls{IoT} applications that operate through specialized \gls{IoT}
networks which often only support low bandwidth.

\Gls{Clean} has a history of interpretation and there is a lot of research
happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
functional intermediate language that is designed to be interpreted. It has
interpreters written in \gls{C++}~\cite{jansen_efficient_2007} and
\gls{Javascript}~\cite{domoszlai_implementing_2011}. Compiler backends exist
for and \gls{Clean} and \gls{Haskell} which compile the respective code to
\gls{SAPL}~\cite{domoszlai_compiling_2012}. The \gls{SAPL} language is still a
functional language and therefore requires big stacks and heaps to operate and
is therefore not directly suitable for devices with little RAM such as the
\gls{Arduino}~Uno which only boasts $2K$ of RAM. It might be possible to
compile the \gls{SAPL} code into efficient machine language or \gls{C} but then
the system would lose its dynamic properties since the microcontroller then
would have to be reprogrammed every time a new \gls{Task} is sent to the
device.

\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}. Again, this
requires a reprogramming cycle every time the \gls{Task}-specification is
changed. Hence, the \gls{EDSL} is used but the backend is not suitable for the
purpose of dynamic \gls{IoT} solutions.

Another \gls{EDSL} designed to generate low-level high-assurance programs is
called \gls{Ivory} and uses \gls{Haskell} as a host language%
~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
make unsafe languages type safe. For example, \gls{Ivory} has been used in the
automotive industry to program parts of an autopilot%
~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
is deeply embedded but the type system is shallowly embedded. This requires
several \gls{Haskell} extensions that offer dependent type constructions. The
process of compiling an \gls{Ivory} program happens in two stages. The embedded
code is transformed into an \gls{AST} that is sent to a chosen backend. The
technique used in the novel system using the \gls{mTask}-\gls{EDSL} is
different, in the new system, the \gls{EDSL} is transformed directly into
functions. There is no intermediate \gls{AST}. Moreover, \gls{Ivory} generates
static programs and thus it is necessary to reprogram the devices when they
need to be repurposed. It would be interesting to explore the possibilities of
writing the client software in an \gls{EDSL} as well.

Not all \gls{IoT} devices run solely compiled code. The popular \emph{ESP8266}
powered \textsc{NodeMCU} is able to run interpreted \gls{LUA} code. Moreover,
there is a variation on \gls{Python} called \emph{micropython} that is suitable
for running on microcontrollers. However, the overhead of the interpreter for
such rich languages often results into limitations on the program size. It
would not be possible to repurpose a device with \gls{IoT} because implementing
this extensibility in the interpreted language leaves no room for the actual
programs. Also, some devices only have $2K$ of ram, which is not enough for
this.
