From 7e2e068caf02d8eae46cddc12ed36445069e67d1 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Sat, 8 Jul 2017 10:21:40 +0200 Subject: [PATCH] more comments --- mtask.class.tex | 33 +++++++++++ mtask.examples.tex | 32 ++++++----- mtask.io.tex | 62 ++++++--------------- mtask.semantics.tex => mtask.scheduling.tex | 7 ++- mtask.tex | 15 +++-- todo.txt | 2 - 6 files changed, 82 insertions(+), 69 deletions(-) create mode 100644 mtask.class.tex rename mtask.semantics.tex => mtask.scheduling.tex (89%) diff --git a/mtask.class.tex b/mtask.class.tex new file mode 100644 index 0000000..684e67d --- /dev/null +++ b/mtask.class.tex @@ -0,0 +1,33 @@ +In the \emph{Arduino} ecosystem, shields are available to plug into the +microcontroller and add functionality. These shields range from Bluetooth, +WiFi, Ethernet, LoRa, LCD screens and much more. Often the functionality +available in these shields is housed in a \gls{C++} class. This functionality +is ported using little work to \gls{mTask} by just creating a corresponding +class with the same functions. As an example, Listing~\ref{lst:lcd} shows parts +of the \gls{LCD} class as an \gls{mTask} class functions and as +Listing~\ref{lst:lcdc} shown the corresponding \emph{Arduino} class functions. + +\begin{lstlisting}[label={lst:lcd},% + caption={Adding the \gls{LCD} to the \gls{mTask} language}] +:: LCD = ... + +class lcd v where + begin :: (v LCD Expr) (v Int p) (v Int q) -> v () Expr + LCD :: Int Int [DigitalPin] ((v LCD Expr) -> Main (v b q)) -> Main (v b q) + ... + scrollLeft :: (v LCD Expr) -> v () Expr + scrollRight :: (v LCD Expr) -> v () Expr + ... +\end{lstlisting} + +\begin{lstlisting}[language=C++,label={lst:lcdc},% + caption={Functions from the \gls{Arduino} \gls{LCD} library}] +class LiquidCrystal { +public: + void begin(uint8_t cols, uint8_t rows); + ... + void scrollDisplayLeft(); + void scrollDisplayRight(); + ... +} +\end{lstlisting} diff --git a/mtask.examples.tex b/mtask.examples.tex index 9277ec6..9369eec 100644 --- a/mtask.examples.tex +++ b/mtask.examples.tex @@ -1,28 +1,32 @@ Some example \gls{mTask}-\glspl{Task} --- using almost all of their -functionality --- are shown in Listing~\ref{lst:exmtask}. The -\gls{mTask}-\glspl{Task} shown in the example do not belong to a particular -view and therefore are of the type \CI{View t r}. The \CI{blink} \gls{mTask} -show the classic \gls{Arduino} blinking \gls{LED} application that blinks a -certain \gls{LED} every second. The \CI{thermostat} expression will enable a -digital pin powering a cooling fan when the analog pin representing a -temperature sensor is too high. \CI{thermostat`} shows the same expression but +functionality --- are shown in Listing~\ref{lst:exmtask}. The \CI{blink} +\gls{mTask} show the classic \gls{Arduino} blinking \gls{LED} application that +blinks a certain \gls{LED} every second. The \CI{thermostat} expression will +enable a digital pin powering a cooling fan when the analog pin representing a +temperature sensor is too high. \CI{thermostat`} shows the same expression but now using the assignment style \gls{GPIO} technique. The \CI{thermostat} example also shows that it is not necessary to run everything as a \CI{task}. The main program code can also just consist of the contents of the root -\CI{main} itself. +\CI{main} itself. Finally a thermostat example is shown that also displays the +temperature on its \gls{LCD} while regulating the temperature. \begin{lstlisting}[% label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}] -blink = task \blink=(\x. +a0 = aIO A0 +d0 = dIO D0 + +blink = task \blink.(\x. IF (x ==. lit True) (ledOn led) (ledOff led) :. blink (lit 1000) (Not x) In {main=blink (lit 1000) True} -thermostat :: Main (View () Stmt) thermostat = {main = digitalWrite D0 (analogRead A0 >. lit 50) } -thermostat` :: Main (View () Stmt) -thermostat` = let - a0 = aIO A0 - d0 = dIO D0 in {main = d0 =. a0 > lit 50 } +thermostat` = {main = d0 =. a0 > lit 50 } + +thermostat`` = task \th.(\lcd. + d0 =. a0 > lit 50 :. + print lcd a0 :. + th (lit 1000) lim ) In + LCD 16 12 [] \lcd.{main = th (lit 1000) lim } \end{lstlisting} diff --git a/mtask.io.tex b/mtask.io.tex index b896da0..2fc83fb 100644 --- a/mtask.io.tex +++ b/mtask.io.tex @@ -8,34 +8,35 @@ assignable entity. \begin{lstlisting}[% label={lst:sdsio},caption={Input/Output classes}] :: DigitalPin = D0 | D1 | D2 | D3 | D4 | D5 |D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 -:: AnalogPin = A0 | A1 | A2 | A3 | A4 | A5 +:: AnalogPin = A0 | A1 | A2 | A3 | A4 | A5 :: UserLED = LED1 | LED2 | LED3 class dIO v where dIO :: DigitalPin -> v Bool Upd class aIO v where aIO :: AnalogPin -> v Int Upd class analogRead v where - analogRead :: AnalogPin -> v Int Expr - analogWrite :: AnalogPin (v Int p) -> v Int Expr + analogRead :: AnalogPin -> v Int Expr + analogWrite :: AnalogPin (v Int p) -> v Int Expr class digitalRead v where - digitalRead :: DigitalPin -> v Bin Expr - digitalWrite :: DigitalPin (v Bool p) -> v Int Expr + digitalRead :: DigitalPin -> v Bin Expr + digitalWrite :: DigitalPin (v Bool p) -> v Int Expr :: UserLED = LED1 | LED2 | LED3 class userLed v where - ledOn :: (v UserLED q) -> (v () Stmt) - ledOff :: (v UserLED q) -> (v () Stmt) + ledOn :: (v UserLED q) -> (v () Stmt) + ledOff :: (v UserLED q) -> (v () Stmt) class assign v where - (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ... + (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ... \end{lstlisting} One way of storing data in \gls{mTask}-\glspl{Task} is using \glspl{SDS}. -\glspl{SDS} serve as variables in \gls{mTask} and maintain their value across -executions. \glspl{SDS} can be used by multiple \glspl{Task} and can be used -to share data. The classes associated with \glspl{SDS} are listed in +\glspl{SDS} serve as global variables in \gls{mTask} and maintain their value +across executions. \glspl{SDS} can be used by multiple \glspl{Task} and can be +used to share data. The classes associated with \glspl{SDS} are listed in Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an \gls{mTask} and make it recognizable by the type system by separating programs -and decorations such as \glspl{SDS}. +and decorations such as \glspl{SDS}. The type signature is complex and uses +infix type constructors and therefore, an implementation example is also given. \begin{lstlisting}[% label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}] @@ -43,38 +44,9 @@ and decorations such as \glspl{SDS}. :: Main a = {main :: a} class sds v where - sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ... -\end{lstlisting} - -In the \emph{Arduino} ecosystem, shields are available to plug into the -microcontroller and add functionality. These shields range from Bluetooth, -WiFi, Ethernet, LoRa, LCD screens and much more. Often the functionality -available in these shields is housed in a \gls{C++} class. This functionality -is ported using little work to \gls{mTask} by just creating a corresponding -class with the same functions. As an example, Listing~\ref{lst:lcd} shows parts -of the \gls{LCD} class as an \gls{mTask} class functions and as -Listing~\ref{lst:lcdc} shown the corresponding \emph{Arduino} class functions. - -\begin{lstlisting}[label={lst:lcd},% - caption={Adding the \gls{LCD} to the \gls{mTask} language}] -:: LCD = ... - -class lcd v where - begin :: (v LCD Expr) (v Int p) (v Int q) -> v () Expr - ... - scrollLeft :: (v LCD Expr) -> v () Expr - scrollRight :: (v LCD Expr) -> v () Expr - ... -\end{lstlisting} + sds :: ((v t Upd) -> In t (Main (v c s))) -> (Main (v c s)) | ... -\begin{lstlisting}[language=C++,label={lst:lcdc},% - caption={Functions from the \gls{Arduino} \gls{LCD} library}] -class LiquidCrystal { -public: - void begin(uint8_t cols, uint8_t rows); - ... - void scrollDisplayLeft(); - void scrollDisplayRight(); - ... -} +sdsExample :: Main (v Int Stmt) +sdsExample = sds \x.0 In + {main= x =. x +. lit 42 } \end{lstlisting} diff --git a/mtask.semantics.tex b/mtask.scheduling.tex similarity index 89% rename from mtask.semantics.tex rename to mtask.scheduling.tex index bf8b910..168b6c6 100644 --- a/mtask.semantics.tex +++ b/mtask.scheduling.tex @@ -1,6 +1,6 @@ The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated alongside the code for the \glspl{Task}. This engine will execute the -\gls{mTask}-\glspl{Task} according to certain rules and semantics. +\gls{mTask}-\glspl{Task} according to certain rules and execution strategies. \gls{mTask}-\glspl{Task} do not behave like functions but more like \gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs out or when it is launched by another \gls{mTask}. When an \gls{mTask} is @@ -8,7 +8,7 @@ queued it does not block the execution and it will return immediately while the actual \gls{Task} will be executed anytime in the future. The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same -semantics. This engine expressed in pseudocode is listed as +scheduling strategy. This engine expressed in pseudocode is listed as Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting time. When the waiting time has not passed; the delta is subtracted and the \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed @@ -53,5 +53,6 @@ indefinitely every one seconds. class mtask v a where task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ... -count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 1000) Zero} +count = task \count = (\n.count (lit 1000) (n +. lit 1)) In + {main = count (lit 1000) (lit 0)} \end{lstlisting} diff --git a/mtask.tex b/mtask.tex index fc0a047..38cd7aa 100644 --- a/mtask.tex +++ b/mtask.tex @@ -15,14 +15,16 @@ A view for the \gls{mTask}-\gls{EDSL} is a type with two free type variables\footnote{kind \CI{*->*->*}.} that implements some of the classes given. The types do not have to be present as fields in the view and can, and will most often, be exclusively phantom types. Thus, views are of the -form:\\\CI{:: v t r = ...}. The first type variable will be the type of the +form: \CI{:: v t r = ...}. The first type variable will be the type of the view. The second type variable will be the type of the \gls{EDSL}-expression and the third type variable represents the role of the expression. Currently the role of the expressions form a hierarchy. The three roles and their hierarchy are shown in Listing~\ref{lst:exprhier}. This implies that everything is a statement, only an \CI{Upd} and an \CI{Expr} are expressions. The \CI{Upd} restriction describes updatable expressions such as \gls{GPIO} pins and -\glspl{SDS}. +\glspl{SDS}. The roles are used to constrain certain classes. For example, +without the roles for \CI{Upd}. Assignment would be possible to a +non-assignable expression such as a literal integer. \begin{lstlisting}[% label={lst:exprhier},caption={Expression role hierarchy}] @@ -41,11 +43,14 @@ instance isExpr Expr \section{Control flow} \input{mtask.control} -\section{Input/Output and Class Extensions} +\section{Input/Output} \input{mtask.io} -\section{Semantics} -\input{mtask.semantics} +\section{Class Extensions} +\input{mtask.class} + +\section{Scheduling Strategy} +\input{mtask.scheduling} \section{Example mTask} \input{mtask.examples} diff --git a/todo.txt b/todo.txt index d8cc4da..efdb1c9 100644 --- a/todo.txt +++ b/todo.txt @@ -1,6 +1,4 @@ intro: Problem statement en introductie uitwijden -mtask: edsl, uitleggen waarom die hierarchie nodig is, isExpr -mtask: voorbeelde sds mtask: semantics anders noemen emtsk: semantics, anders noemen en voorbeelden geven in strategies emtsk: Voorbeeldje voor namedsds -- 2.20.1