From 0e65bdb41aba272dc3a58ba525acd8d5bda35e84 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Thu, 10 Nov 2022 19:57:22 +0100 Subject: [PATCH] . --- intro/intro.tex | 67 +++++++++++++++++++------------------------------ 1 file changed, 26 insertions(+), 41 deletions(-) diff --git a/intro/intro.tex b/intro/intro.tex index 745a6ab..2444aec 100644 --- a/intro/intro.tex +++ b/intro/intro.tex @@ -102,6 +102,7 @@ There is more linguistic reuse~\cite{krishnamurthi_linguistic_2001}. There are however two sides to the this coin. If the syntax of the host language is not very flexible, the syntax of the \gls{DSL} may become clumsy. Furthermore, errors shown to the programmer may be larded with host language errors, making it difficult for a non-expert of the host language to work with the \gls{DSL}. +Pure \gls{FP} languages are especially suitable for hosting embedded \glspl{DSL} because they have strong and versatile type systems, minimal but flexible syntax and offer referential transparency. \subsection{Heterogeneity and homogeneity} \Citet{tratt_domain_2008} applied a notion from metaprogramming \citep{sheard_accomplishments_2001} to \glspl{EDSL} to define homogeneity and heterogeneity of \glspl{EDSL} as follows: @@ -123,6 +124,9 @@ In fact, \gls{ITASK} and \gls{MTASK} are both heterogeneous \glspl{EDSL} and \gl \section{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}\label{sec:back_top} \Gls{TOP} is a declarative programming paradigm designed to model interactive systems \citep{plasmeijer_task-oriented_2012}. +\Citet{steenvoorden_tophat_2022} defines two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines. +A \gls{TOP} language is the formal language to specify workflows. +A \gls{TOP} engine executes such a specification as a ready-for-work application. Instead of dividing problems into layers or tiers, as is done in \gls{IOT} architectures, it deals with separation of concerns in a novel way. From the data types, utilising various \emph{type-parametrised} concepts, all other aspects are handled automatically (see \cref{fig:tosd}). This approach to software development is called \gls{TOSD} \citep{wang_maintaining_2018}. @@ -165,66 +169,47 @@ This approach to software development is called \gls{TOSD} \citep{wang_maintaini \subsection{\texorpdfstring{\Gls{ITASK}}{ITask}} -The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative workflow language for defining multi-user distributed web applications implemented as an \gls{EDSL} in the lazy pure \gls{FP} language \gls{CLEAN} \citep{plasmeijer_itasks:_2007,plasmeijer_task-oriented_2012}. +The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative workflow language and \gls{TOP} engine for defining multi-user distributed web applications implemented as an \gls{EDSL} in the lazy pure \gls{FP} language \gls{CLEAN} \citep{plasmeijer_itasks:_2007,plasmeijer_task-oriented_2012}. From the structural properties of the data types, the entire user interface is automatically generated. -As an example, \cref{fig:enter_person} shows the \gls{ITASK} code and the corresponding \gls{UI} for a simple task for entering a person. -From the data type definitions (\crefrange{lst:dt_fro}{lst:dt_to}), using generic programming (\cref{lst:dt_derive}), the \glspl{UI} for the data types are automatically generated. +As an example, \cref{lst:enter_person,fig:enter_person} show the \gls{ITASK} code and the corresponding \gls{UI} for a simple task for entering a person. +From the data type definitions (\cref{lst:dt_fro,lst:dt_to}), using generic programming (\cref{lst:dt_derive}), the \glspl{UI} for the data types are automatically generated. Using task combinators (see \cleaninline{>>!} at \cref{lst:task_comb}), the tasks can be combined in sequence. Only when the user entered a complete value in the web editor, then the continue button enables and the result can be viewed. Special combinators (e.g.\ \cleaninline{@>>} at \cref{lst:task_ui}) are available to tweak the \gls{UI} afterwards. \begin{figure}[ht] - \begin{subfigure}[b]{.525\linewidth} - \begin{lstClean} -:: Person =[+\label{lst:dt_fro}+] - { name :: String - , gender :: Gender - , dateOfBirth :: Date - } - -:: Gender - = Male - | Female - | Other String[+\label{lst:dt_to}+] + \includegraphics[width=.32\linewidth]{person0} + \includegraphics[width=.32\linewidth]{person1} + \includegraphics[width=.32\linewidth]{person2} + \caption{The \gls{UI} for entering a person in \gls{ITASK}.}% + \label{fig:enter_person} +\end{figure} + +\begin{lstClean}[numbers=left,caption={The \gls{UI} and code for entering a person in \gls{ITASK}.},label={lst:enter_person}] +:: Person = { name :: String, gender :: Gender, dateOfBirth :: Date }[+\label{lst:dt_fro}+] +:: Gender = Male | Female | Other String[+\label{lst:dt_to}+] derive class iTask Person, Gender[+\label{lst:dt_derive}+] enterPerson :: Task Person enterPerson - = Hint "Enter a person:" - @>> enterInformation [] [+\label{lst:task_ui}+] - >>! \result -> Hint "You Entered:"[+\label{lst:task_comb}+] - @>> viewInformation [] result - \end{lstClean} - \caption{\Gls{CLEAN} code} - \end{subfigure}% - \begin{subfigure}[b]{.475\linewidth} - \includegraphics[width=\linewidth]{person0} - \includegraphics[width=\linewidth]{person1} - \includegraphics[width=\linewidth]{person2} - \caption{\Glsxtrlong{UI}} - \end{subfigure} - \caption{The \gls{UI} and code for entering a person in \gls{ITASK}.}% - \label{fig:enter_person} -\end{figure} + = Hint "Enter a person:" @>> enterInformation [][+\label{lst:task_ui}+] + >>! \result->Hint "You Entered:" @>> viewInformation [] result[+\label{lst:task_comb}+] +\end{lstClean} \subsection{Other \texorpdfstring{\glsxtrshort{TOP}}{TOP} languages} -\Citet{steenvoorden_tophat_2022} defines two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines. -A \gls{TOP} language is a formal language to specify workflows. -A \gls{TOP} engine executes such a specification as a ready-for-work application. -The \gls{ITASK} system is both a \gls{TOP} language and an engine. -While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} language. +While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} language and engine. Some \gls{TOP} languages and systems arose from Master's and Bachelor's thesis projects (e.g.\ \textmu{}Task \citep{piers_task-oriented_2016} and LTasks \citep{van_gemert_task_2022}) or were created to solve a practical problem (e.g.\ Toppyt \citep{lijnse_toppyt_2022} and hTask \citep{lubbers_htask_2022}). Furthermore, \gls{TOPHAT} is a fully formally specified \gls{TOP} language designed to capture the essence of \gls{TOP} formally \citep{steenvoorden_tophat_2019}. It is also possible to translate \gls{TOPHAT} code to \gls{ITASK} to piggyback on the \gls{TOP} engine it offers. \subsection{\texorpdfstring{\Gls{MTASK}}{MTask}} -Finally there is \gls{MTASK}, a \gls{TOP} language designed for defining workflows for \gls{IOT} edge devices \citep{koopman_task-based_2018}. -It is written in \gls{CLEAN} as a multi-view \gls{EDSL} fully integrated with \gls{ITASK}. -Together with \gls{ITASK}, it allows the programmer to define all layers of an \gls{IOT} system from a single declarative specification. -The domain-specific nature of the language allows for a very compact binary representation of the work that needs to be done. -This specification can be interpreted on a device that runs the \gls{MTASK} \gls{RTS}, a domain-specific \gls{TOP} engine implemented as a feather-light domain-specific \gls{OS}. +This thesis uses a novel \gls{TOP} language designed for defining workflows for \gls{IOT} edge devices \citep{koopman_task-based_2018}. +It is written in \gls{CLEAN} as a multi-view \gls{EDSL} and hence there are multiple interpretations of the language of which the byte code compiler is the most relevant for this thesis. +From the terms in the \gls{TOP} language, a very compact binary representation of the work that needs to be done is compiled. +This specification is then sent to a device that runs the \gls{MTASK} \gls{RTS}, a domain-specific \gls{TOP} engine implemented as a feather-light domain-specific \gls{OS}. +\Gls{MTASK} is seemlessly integrated with \gls{ITASK}, it allows the programmer to define all layers of an \gls{IOT} system from a single declarative specification. \section{Reading guide and contributions}\label{sec:contributions} This novel view on programming \gls{IOT} systems is presented in the thesis as a purely functional rhapsody in three episodes. -- 2.20.1