rename faulty files and elaborate in the system chapter

[msc-thesis1617.git] / system.edsl.tex

diff --git a/system.edsl.tex b/system.edsl.tex
index c44ffcc..ee783b9 100644 (file)
--- a/system.edsl.tex
+++ b/system.edsl.tex
@@ -1,9 +1,9 @@
 Not all \glspl{Task} are suitable to run on an \gls{IoT}-device and therefore
-an \gls{EDSL} is used to offer a constrained language to express \glspl{Task}
-for the new system in. The \gls{mTask}-\gls{EDSL} shown in
-Chapter~\ref{chp:mtask} provides a language to create imperative programs that
+an \gls{EDSL} is used to offer a constrained language that expresses \glspl{Task}
+for the new system. The \gls{mTask}-\gls{EDSL} shown in
+Chapter~\ref{chp:mtask} provides the language to create imperative programs that
 are suitable to run on microcontrollers. The \gls{EDSL}'s main view is a
-\gls{C} code generator who's code compiles for \gls{Arduino} compatible
+\gls{C} code generator who's code compiles to \gls{Arduino} compatible
 microcontrollers. The big downside of this approach is the stiffness of the
 system. Once the code has been generated and the microcontroller has been
 programmed, nothing can be changed to it anymore. \gls{IoT}-devices often have
@@ -12,7 +12,7 @@ therefore it is very expensive to keep recompiling and reprogramming the chips.
 To solve this problem, a new view is proposed for the \gls{mTask}-\gls{EDSL}
 which compiles the expressions not to \gls{C}-code, but to a bytecode format.
 To achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
-Some functionality of the \gls{mTask} system is not used.
+Not all of the functionality of the \gls{mTask} language is used.
 
 The added functionality and implementation to the \gls{mTask}-\gls{EDSL} is
 shown in Chapter~\ref{chp:mtaskcont}.