From 20834af74e4bb3a12a20a03de5c4cab5c6e46eb7 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Wed, 12 Jul 2017 16:13:27 +0200 Subject: [PATCH] more stuff --- intro.related.tex | 68 ++++++++++++++++++++++++++--------------------- 1 file changed, 38 insertions(+), 30 deletions(-) diff --git a/intro.related.tex b/intro.related.tex index bca403f..69f2166 100644 --- a/intro.related.tex +++ b/intro.related.tex @@ -1,38 +1,43 @@ 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% @@ -42,8 +47,11 @@ 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 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. -- 2.20.1