intro.related.tex

   1 Similar research has been conducted on the subject.
   2 For example, microcontrollers such as the \gls{Arduino} can be remotely
   3 controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
   4 Documentation of the Firmata protocol.''
   5 (\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
   6 protocol is designed to expose the peripherals such as sensors to a server.
   7 This allows very fine grained control but with the cost of excessive
   8 communication overhead since no code is executed on the device itself, only the
   9 peripherals are queried. A \gls{Haskell} implementation of the protocol is
  10 also available\footnote{``hArduino by LeventErkok.'' (\url{%
  11 https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. The
  12 hardware requirements for running a \gls{Firmata} client are very low. However,
  13 the communication requirements are high and therefore it is not suitable for
  14 \gls{IoT} applications that operate through specialized \gls{IoT} networks
  15 which often have low bandwidth and low power properties.
  16
  17 \Gls{Clean} has a history of interpretation and there is a lot of research
  18 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
  19 functional intermediate language that has interpreters written in
  20 \gls{C++}~\cite{jansen_efficient_2007}, \gls{Javascript}%
  21 ~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
  22 backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
  23 code is still heap-heavy and therefore not directly suitable for devices with
  24 as little as $2K$ of RAM such as the \gls{Arduino} \emph{Uno}. It might be
  25 possible to compile the \gls{SAPL} code into efficient machine language or
  26 \gls{C} but then the system would lose its dynamic properties since the
  27 microcontroller then would have to be reprogrammed every time a new \gls{Task}
  28 is sent to the device.
  29
  30 \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
  31 environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
  32 generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
  33 ~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}.  Again, this
  34 requires a reprogramming cycle every time the \gls{Task}-specification is
  35 changed.
  36
  37 Another \gls{EDSL} designed to generate low-level high-assurance programs is
  38 called \gls{Ivory} and uses \gls{Haskell} as a host language%
  39 ~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
  40 make unsafe languages type safe. For example, \gls{Ivory} has been used in the
  41 automotive industry to program parts of an autopilot%
  42 ~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
  43 is deeply embedded but the type system is shallowly embedded. This requires
  44 several \gls{Haskell} extensions that offer dependent type constructions. The
  45 process of compiling an \gls{Ivory} program happens in stages. The embedded
  46 code is transformed into an \gls{AST} that is sent to a backend. In the new
  47 system, the \gls{mTask}-\gls{EDSL} transforms the embedded code during
  48 compile-time directly into the backend which is often a state transformer that
  49 will execute on runtime.