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:
\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}.
\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.
repositories / phd-thesis.git / commitdiff