Merge branch 'master' of git.martlubbers.net:msc-thesis1617

[msc-thesis1617.git] / intro.related.tex

diff --git a/intro.related.tex b/intro.related.tex
index 69f2166..de306e5 100644 (file)
--- a/intro.related.tex
+++ b/intro.related.tex
@@ -25,7 +25,7 @@ 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
+\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
@@ -55,3 +55,13 @@ 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.