Similar research has been conducted on the subject.
For example, microcontrollers such as the \gls{Arduino} can be remotely
-controlled by 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 expose the peripherals such as sensors to a server.
-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 have low bandwidth and low power properties.
+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 has interpreters written in
-\gls{C++}~\cite{jansen_efficient_2007}, \gls{Javascript}%
-~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
-backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
-code is still heap-heavy and therefore not directly suitable for devices with
-as little as $2K$ of RAM such as the \gls{Arduino} \emph{Uno}. 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.
+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
+~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}. Again, this
requires a reprogramming cycle every time the \gls{Task}-specification is
-changed.
+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{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 stages. The embedded
-code is transformed into an \gls{AST} that is sent to a backend. In the new
-system, the \gls{mTask}-\gls{EDSL} transforms the embedded code during
-compile-time directly into the backend which is often a state transformer that
-will execute on runtime.
+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.
repositories / msc-thesis1617.git / commitdiff