-@PREAMBLE{ {\providecommand{\noopsort}[1]{}} }
+@PREAMBLE{ {\providecommand{\noopsort}[2]{#2} } }
@inproceedings{suchocki_microscheme:_2015,
address = {Washington DC, USA},
series = {{CS} {Techreport} 718},
abstract = {Clean is an experimental language for specifying functional computations in terms of graph rewriting. It is based on an extension of Term Rewriting Systems (TRS) in which the terms are replaced by graphs. Such a Graph Rewriting System (GRS) consists of a, possibly cyclic, directed graph, called the data graph and graph rewrite rules which specify how this data graph may be rewritten. Clean is designed to provide a firm base for functional programming. In particular, Clean is suitable as an intermediate language between functional languages and (parallel) target machine architectures. A sequential implementation of Clean on a conventional machine is described and its performance is compared with other systems. The results show that Clean can be efficiently implemented.},
booktitle = {Functional {Programming} {Languages} and {Computer} {Architecture}},
publisher = {Springer Berlin Heidelberg},
- author = {Brus, T. H. and {\noopsort{Eekelen}van Eekelen}, M. C. J. D. and {\noopsort{Leer}van Leer}, M. O. and Plasmeijer, M. J.},
+ author = {Brus, T. H. and \noopsort{Eekelen}{van Eekelen}, M. C. J. D. and \noopsort{Leer}{van Leer}, M. O. and Plasmeijer, M. J.},
editor = {Kahn, Gilles},
year = {1987},
pages = {364--384},
volume = {1},
booktitle = {{PARLE}, {Parallel} {Architectures} and {Languages} {Europe}},
publisher = {Springer Verlag},
- author = {Barendregt, H.P. and {\noopsort{Eekelen}van Eekelen}, M.C.J.D and Glauert, J.R.W. and Kennaway, J.R. and Plasmeijer, M.J. and Sleep, M.R.},
+ author = {Barendregt, H.P. and \noopsort{Eekelen}{van Eekelen}, M.C.J.D and Glauert, J.R.W. and Kennaway, J.R. and Plasmeijer, M.J. and Sleep, M.R.},
year = {1987},
pages = {159--174},
file = {barh87-Lean.ps.gz:/home/mrl/.local/share/zotero/storage/63FBHND7/barh87-Lean.ps.gz:application/gzip;barh87-Lean.ps.gz:/home/mrl/.local/share/zotero/storage/6H2UKQGZ/barh87-Lean.ps.gz:application/gzip},
shorttitle = {Exchanging sources between {Clean} and {Haskell}},
number = {11},
journal = {ACM Sigplan Notices},
- author = {{\noopsort{Groningen}van Groningen}, John and {\noopsort{Noort}van Noort}, Thomas and Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
+ author = {\noopsort{Groningen}{van Groningen}, John and \noopsort{Noort}{van Noort}, Thomas and Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
year = {2010},
pages = {49--60},
file = {groj10-Haskell_front_end_Clean.pdf:/home/mrl/.local/share/zotero/storage/WVZWX8WT/groj10-Haskell_front_end_Clean.pdf:application/pdf},
doi = {10.1017/S0956796802004574},
number = {3},
journal = {Journal of Functional Programming},
- author = {Elliott, Conal and Finne, Sigbjørn and {\noopsort{Moor}de Moor}, Oege},
+ author = {Elliott, Conal and Finne, Sigbjørn and \noopsort{Moor}{de Moor}, Oege},
year = {2003},
note = {Publisher: Cambridge University Press},
pages = {455--481},
title = {Clean {Language} {Report} version 3.1},
urldate = {2021-12-22},
institution = {Institute for Computing and Information Sciences},
- author = {Plasmeijer, Rinus and {\noopsort{Eekelen}van Eekelen}, Marko and {\noopsort{Groningen}van Groningen}, John},
+ author = {Plasmeijer, Rinus and \noopsort{Eekelen}{van Eekelen}, Marko and \noopsort{Groningen}{van Groningen}, John},
month = dec,
year = {2021},
pages = {127},
abstract = {Concurrent Clean is an experimental, lazy, higher-order parallel functional programming language based on term graph rewriting. An important difference with other languages is that in Clean graphs are manipulated and not terms. This can be used by the programmer to control communication and sharing of computation. Cyclic structures can be defined. Concurrent Clean furthermore allows to control the (parallel) order of evaluation to make efficient evaluation possible. With help of sequential annotations the default lazy evaluation can be locally changed into eager evaluation. The language enables the definition of partially strict data structures which make a whole new class of algorithms feasible in a functional language. A powerful and fast strictness analyser is incorporated in the system. The quality of the code generated by the Clean compiler has been greatly improved such that it is one of the best code generators for a lazy functional language. Two very powerful parallel annotations enable the programmer to define concurrent functional programs with arbitrary process topologies. Concurrent Clean is set up in such a way that the efficiency achieved for the sequential case can largely be maintained for a parallel implementation on loosely coupled parallel machine architectures.},
booktitle = {{PARLE} '91 {Parallel} {Architectures} and {Languages} {Europe}},
publisher = {Springer Berlin Heidelberg},
- author = {N\"{o}cker, E. G. J. M. H. and Smetsers, J. E. W. and {\noopsort{Eekelen}van Eekelen}, M. C. J. D. and Plasmeijer, M. J.},
+ author = {N\"{o}cker, E. G. J. M. H. and Smetsers, J. E. W. and \noopsort{Eekelen}{van Eekelen}, M. C. J. D. and Plasmeijer, M. J.},
editor = {Aarts, Emile H. L. and van Leeuwen, Jan and Rem, Martin},
year = {1991},
pages = {202--219},
abstract = {More and more applications rely on the safe execution of code unknown at compile-time, for example in the implementation of web browsers and plugin systems. Furthermore, these applications usually require some form of communication between the added code and its embedder, and hence a communication channel must be set up in which values are serialized and deserialized. This paper shows that in a functional programming language we can solve these two problems at once, if we realize that the execution of extra code is nothing more than the deserialization of a value which happens to be a function. To demonstrate this, we describe the implementation of a serialization library for the language Clean, which internally uses an interpreter to evaluate added code in a separate, sandboxed environment. Remarkable is that despite the conceptual asymmetry between "host" and "interpreter", lazy interworking must be implemented in a highly symmetric fashion, much akin to distributed systems. The library interworks on a low level with the native Clean program, but has been implemented without any changes to the native runtime system. It can therefore easily be ported to other programming languages.We can use the same technique in the context of the web, where we want to be able to share possibly lazy values between a server and a client. In this case the interpreter runs in WebAssembly in the browser and communicates seamlessly with the server, written in Clean. We use this in the iTasks web framework to handle communication and offload computations to the client to reduce stress on the server-side. Previously, this framework cross-compiled the Clean source code to JavaScript and used JSON for communication. The interpreter has a more predictable and better performance, and integration is much simpler because it interworks on a lower level with the web server.},
booktitle = {Proceedings of the 31st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
publisher = {ACM},
- author = {Staps, Camil and {\noopsort{Groningen}van Groningen}, John and Plasmeijer, Rinus},
+ author = {Staps, Camil and \noopsort{Groningen}{van Groningen}, John and Plasmeijer, Rinus},
year = {2019},
note = {event-place: Singapore, Singapore},
keywords = {functional programming, interpreters, laziness, sandboxing, web-assembly},
abstract = {The interface with the outside world has always been one of the weakest points of functional languages. It is not easy to incorporate I/O without being allowed to do side-effects. Furthermore, functional languages allow redexes to be evaluated in any order while I/O generally has to be performed in a very specific order. In this paper we present a new solution for the I/O problem which we have incorporated in the language Concurrent Clean. Concurrent Clean offers a linear type system called Unique Types. It makes it possible to define functions with side-effects without violating the functional semantics. Now it is possible to change any object in the world in the way we wanted: e.g. arrays can be updated in-situ, arbitrary file manipulation is possible. We have used this powerful tool among others to create a library for window based I/O. Using an explicit environment passing scheme provides a high-level and elegant functional specification method for I/O, called Event I/O. Now the specification of I/O has become one of the strengths of functional languages: interactive programs written in Concurrent Clean are concise, easy to write and comprehend as well as efficient. The presented solution can in principle be applied for any other functional language as well provided that it actually uses graph rewriting semantics in the implementation.},
booktitle = {Functional {Programming}, {Glasgow} 1992},
publisher = {Springer London},
- author = {Achten, Peter and {\noopsort{Groningen}van Groningen}, John and Plasmeijer, Rinus},
+ author = {Achten, Peter and \noopsort{Groningen}{van Groningen}, John and Plasmeijer, Rinus},
editor = {Launchbury, John and Sansom, Patrick},
year = {1993},
pages = {1--17},
abstract = {Differences in features supported by the various contemporary commercial workflow management systems point to different insights of suitability and different levels of expressive power. The challenge, which we undertake in this paper, is to systematically address workflow requirements, from basic to complex. Many of the more complex requirements identified, recur quite frequently in the analysis phases of workflow projects, however their implementation is uncertain in current products. Requirements for workflow languages are indicated through workflow patterns. In this context, patterns address business requirements in an imperative workflow style expression, but are removed from specific workflow languages. The paper describes a number of workflow patterns addressing what we believe identify comprehensive workflow functionality. These patterns provide the basis for an in-depth comparison of a number of commercially availablework flow management systems. As such, this paper can be seen as the academic response to evaluations made by prestigious consulting companies. Typically, these evaluations hardly consider the workflow modeling language and routing capabilities, and focus more on the purely technical and commercial aspects.},
number = {1},
journal = {Distributed and Parallel Databases},
- author = {{\noopsort{Aalst}van der Aalst}, W.M.P. and {\noopsort{Hofstede}ter Hofstede}, A.H.M. and Kiepuszewski, B. and Barros, A.P.},
+ author = {\noopsort{Aalst}{van der Aalst}, W.M.P. and \noopsort{Hofstede}{ter Hofstede}, A.H.M. and Kiepuszewski, B. and Barros, A.P.},
month = jul,
year = {2003},
pages = {5--51},
-@PREAMBLE{ {\providecommand{\noopsort}[1]{}} }
+@PREAMBLE{ {\providecommand{\noopsort}[2]{#2} } }
@inproceedings{lubbers_interpreting_2019,
address = {New York, NY, USA},
series = {{IFL} '19},
}
@article{lubbers_could_2022,
- title = {Could {Tierless} {Languages} {Reduce} {IoT} {Development} {Grief}?},
+ author = {Lubbers, Mart and Koopman, Pieter and Ramsingh, Adrian and Singer, Jeremy and Trinder, Phil},
+ title = {Could Tierless Languages Reduce IoT Development Grief?},
+ year = {2023},
+ issue_date = {February 2023},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ volume = {4},
+ number = {1},
issn = {2691-1914},
+ url = {https://doi.org/10.1145/3572901},
doi = {10.1145/3572901},
- abstract = {Internet of Things (IoT) software is notoriously complex, conventionally comprising multiple tiers. Traditionally an IoT developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single tierless language with a compiler that generates the code for each component and ensures their correct interoperation. We report a systematic comparative evaluation of two tierless language technologies for IoT stacks: one for resource-rich sensor nodes (Clean with iTask), and one for resource-constrained sensor nodes (Clean with iTask and mTask). The evaluation is based on four implementations of a typical smart campus application: two tierless and two Python-based tiered. (1) We show that tierless languages have the potential to significantly reduce the development effort for IoT systems, requiring 70\% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g. two embedded domain-specific languages (DSLs) and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful IoT programming abstractions. (2) We show that tierless languages have the potential to significantly improve the reliability of IoT systems, describing how Clean iTask/mTask maintains type safety, provides higher order failure management, and simplifies maintainability. (3) We report the first comparison of a tierless IoT codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes. The comparison shows that they have similar code size (within 7\%), and functional structure. (4) We present the first comparison of two tierless IoT languages, one for resource-rich sensor nodes, and the other for resource-constrained sensor nodes.},
+ abstract = {Internet of Things (IoT) software is notoriously complex, conventionally comprising multiple tiers. Traditionally an IoT developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single tierless language with a compiler that generates the code for each component and ensures their correct interoperation.We report a systematic comparative evaluation of two tierless language technologies for IoT stacks: one for resource-rich sensor nodes (Clean with iTask) and one for resource-constrained sensor nodes (Clean with iTask and mTask). The evaluation is based on four implementations of a typical smart campus application: two tierless and two Python-based tiered.(1) We show that tierless languages have the potential to significantly reduce the development effort for IoT systems, requiring 70% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g., two embedded domain-specific languages and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful IoT programming abstractions. (2) We show that tierless languages have the potential to significantly improve the reliability of IoT systems, describing how Clean iTask/mTask maintains type safety, provides higher-order failure management, and simplifies maintainability. (3) We report the first comparison of a tierless IoT codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes. The comparison shows that they have similar code size (within 7%), and functional structure. (4) We present the first comparison of two tierless IoT languages, one for resource-rich sensor nodes and the other for resource-constrained sensor nodes.},
journal = {ACM Trans. Internet Things},
- author = {Lubbers, Mart and Koopman, Pieter and Ramsingh, Adrian and Singer, Jeremy and Trinder, Phil},
- month = nov,
- year = {2022},
- note = {Place: New York, NY, USA
-Publisher: ACM},
- keywords = {access control, internet-of-things, policy language, privilege escalation, Smart home system, IoT stacks, Tierless languages},
+ month = {feb},
+ articleno = {6},
+ numpages = {35},
+ keywords = {IoT stacks, Tierless languages}
}
@inproceedings{koopman_strongly-typed_2022,
-@PREAMBLE{ {\providecommand{\noopsort}[1]{}} }
+@PREAMBLE{ {\providecommand{\noopsort}[2]{#2} } }
@Article{ sethi2017internet,
title = {Internet of things: architectures, protocols, and
applications},
}
@InProceedings{ motta2018challenges,
- author = {Motta, Rebeca C. and {\noopsort{Oliveira}de Oliveira}, K\'{a}thia M. and Travassos, Guilherme H.},
+ author = {Motta, Rebeca C. and \noopsort{Oliveira}{de Oliveira}, K\'{a}thia M. and Travassos, Guilherme H.},
title = {On Challenges in Engineering IoT Software Systems},
year = {2018},
isbn = {9781450365031},
and {Application} of {Functional} {Programming}
{Languages}},
publisher = {ACM},
- author = {Oortgiese, Arjan and {\noopsort{Groningen}van Groningen}, John and Achten, Peter
+ author = {Oortgiese, Arjan and \noopsort{Groningen}{van Groningen}, John and Achten, Peter
and Plasmeijer, Rinus},
year = {2017},
pages = {7},
}
@InProceedings{ 10.1145/2661136.2661146,
- author = {Philips, Laure and {\noopsort{Roover}de Roover}, Coen and {\noopsort{Cutsem}van Cutsem}, Tom and {\noopsort{Meuter}de Meuter}, Wolfgang},
+ author = {Philips, Laure and \noopsort{Roover}{de Roover}, Coen and \noopsort{Cutsem}{van Cutsem}, Tom and \noopsort{Meuter}{de Meuter}, Wolfgang},
title = {Towards Tierless Web Development without Tierless
Languages},
year = {2014},
\usepackage[square]{natbib} % Cite bib entry completely
+
\setlength{\bibsep}{0.0pt}
\def\bibfont{\footnotesize}
%\setcitestyle{numbers}
How an \gls{MTASK} task is compiled to this specification is shown in \cref{sec:compiler_imp}.
This package is then sent to the \gls{RTS} of the device for execution.
In order to execute a task, first the main expression is evaluated in the interpreter, resulting in a task tree.
-Using small-step reduction, this task tree is continuously rewritten by the rewrite engine of the \gls{RTS}.
+Then, using small-step reduction, the task tree is continuously rewritten by the rewrite engine of the \gls{RTS}.
At times, the reduction requires the evaluation of expressions, using the interpreter.
During every rewrite step, a task value is produced.
On the device, the \gls{RTS} may have multiple tasks at the same time active.
\end{figure}
\section{Compiler}\label{sec:compiler_imp}
+\todo[inline]{Zou je hier niet een prargraafje schrijven over dat dit een beetje speciale compiler is. Alle type checks worden al door Clean gedaan. Dat is voordat deze compiler ooit uitgevoerd gaat worden. Bovendien kan het Clean programma de te compileren byte code dynamisch maken. Dat staat natuurlijk al eerder een keer, maar je make niet aannemen dat iedereen alles leest (en nu nog weet)}
+\todo[inline]{Dit gaat wel hard de diepte in. Zou je niet een kort stukje schrijven over hoe je bytecode machine er uit ziet?
+ Heap: voor de huidige task tree die herschreven wordt.
+ Function code: sequence of bytecode instructie.
+ SDSs + Objects
+ Stack om expressies te evelaueren en function calls te doen.
+ Plaatje a la Figure 7.5.
+
+ Om de code te maken heb je een intsantie van alle classen in mTask nodig voor BCInterpret a.
+
+Voor veel lezers zou het genoeg zijn om alleen dat te snappen, maak het ze eenvoudig.}
\subsection{Compiler infrastructure}
The byte code compiler interpretation for the \gls{MTASK} language is implemented as a monad stack containing a writer monad and a state monad.
The writer monad is used to generate code snippets locally without having to store them in the monadic values.
Some optimisation is possible here but has currently not been implemented.
\begin{align*}
- \cschemeE{t_1\text{\cleaninline{>>*.}}t_2}{r} & =
+ \cschemeE{t_1\text{\cleaninline{>>*.}}e_2}{r} & =
\cschemeE{a_{f^i}}{r}, \langle f, i\rangle\in r;
\text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCStable}}_{\stacksize{r}}; \cschemeE{t_1}{r};\\
- {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCAnd}}; \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCStep}}~(\cschemeS{t_2}{(r + [\langle l_s, i\rangle])}{\stacksize{t_1}}));\\
+ {} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}}~\text{\cleaninline{BCAnd}}; \text{\cleaninline{BCMkTask}}~(\text{\cleaninline{BCStep}}~(\cschemeS{e_2}{(r + [\langle l_s, i\rangle])}{\stacksize{t_1}}));\\
\end{align*}
\begin{align*}
{} & \text{\emph{Similar for \cleaninline{IfStable} and \cleaninline{IfUnstable}}}\\
\end{align*}
-First the context is evaluated.
+The step combinator has a task as the left-hand side and a list of continuations at the right-hand side.
+First the context is evaluated ($\cschemeE{a_{f^i}}{r}$).
The context contains arguments from functions and steps that need to be preserved after rewriting.
-The evaluated context is combined with the left-hand side task value by means of a \cleaninline{.&&.} combinator to store it in the task tree so that it is available after a rewrite.
+The evaluated context is combined with the left-hand side task value by means of a \cleaninline{.&&.} combinator to store it in the task tree so that it is available after a rewrite step.
This means that the task tree is transformed as seen in \cref{lst:context_tree}.
+In this figure, the expression \cleaninline{t1 >>=. \v1->t2 >>=. \v2->...} is shown\footnote{%
+ \cleaninline{t >>=. e} is a shorthand combinator for \cleaninline{t >>* [OnStable (\_->true) e].}}.
+Then, the right-hand side list of continuations is converted to an expression using $\mathcal{S}$.
+\todo[inline]{Beter uitleggen?}
\begin{figure}
\begin{subfigure}{.5\textwidth}
\end{lstClean}
\subsection{Shared data sources}\label{lst:imp_sds}
-The compilation scheme for \gls{SDS} definitions is a trivial extension to $\mathcal{F}$ since there is no code generated as seen below.
+The compilation scheme for \gls{SDS} definitions is a trivial extension to $\mathcal{F}$.
+While there is no code generated, metadata is added to the compiler state identifying the \gls{SDS}, this is seen later in \cref{lst:comp_sds}.
\begin{align*}
\cschemeF{\text{\cleaninline{sds}}~x=i~\text{\cleaninline{In}}~m} & =
The second phase performs one execution step for all tasks that wish for it.
Tasks are ordered in a priority queue ordered by the time a task needs to execute, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
Execution of a task is always an interplay between the interpreter and the rewriter.
+\todo[inline]{ik denk dat die rewriter een paar woorden uitleg kan gebruiken.
+The rewriter scans the current task tree and tries to reqrite it. Expressions in the tree are evaluated by the interpreter.\ o.i.d.}
When a new task is received, the main expression is evaluated to produce a task tree.
A task tree is a tree structure in which each node represents a task combinator and the leaves are basic tasks.
If a task is not initialised yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
-The main expression always produces a task tree.
+The main expression of \gls{MTASK} programs always produces a task tree.\todo[inline]{note dat mtask programmas altijd taken zijn, je kunt niet een niet-taak expressie opsturen naar een device}
Execution of a task consists of continuously rewriting the task until its value is stable.
Rewriting is a destructive process, i.e.\ the rewriting is done in place.
Take for example a blink task for which the code is shown in \cref{lst:blink_code}.
\begin{lstClean}[caption={Code for a blink program.},label={lst:blink_code}]
-fun \blink=(\st->delay (lit 500) >>|. writeD d3 st >>=. blink o Not)
+declarePin D13 PMOutput \ledPin->
+fun \blink=(\st->delay (lit 500) >>|. writeD ledPin st >>=. blink o Not)
In {main = blink true}
\end{lstClean}
When \cleaninline{writeD} becomes stable, the written value is the task value that is observed by the right-hand side of the \cleaninline{>>=.} combinator.
This will call the interpreter to evaluate the expression, now that the argument of the function is known.
The result of the function is again a task tree, but now with different arguments to the tasks, e.g.\ the state in \cleaninline{writeD} is inversed.
+\todo[inline]{Beter uitleggen dat \cleaninline{>>\|.} eigenlijk een step is en dat het natuurlijk eigenlijk twee trees zijn.}
\begin{figure}
\centering
Using \cleaninline{liftmTask}, \gls{MTASK} tasks are lifted to a device (see \cref{sec:liftmtask}).
\glspl{SDS} from \gls{ITASK} are lowered to the \gls{MTASK} device using \cleaninline{lowerSds} (see \cref{sec:liftsds}).
\todo[inline]{mTask device\textsubscript{n} naar hfstk 5? Uitleg over taken en sensoren en \ldots? evt.\ zelfs naar intro hmmm?}
+\todo[inline]{Benoem dat er meerdere devices kunnen zijn en meerdere tasks op één device, en verwijs naar 6.5}
\begin{figure}
\centering
\end{enumerate}
\begin{lstClean}[caption={Pseudocode for the \texttt{withDevice} function in \gls{MTASK}.},label={lst:pseudo_withdevice}]
+withDevice :: a (MTDevice -> Task b) -> Task b | ...
withDevice spec deviceTask =
- withShared default \dev->parallel
+ withShared default \dev->
withShared newMap \sdsupdates->
withShared ([], [MTTSpecRequest], False) \channels->
- [ channelSync spec channels
- , watchForShutdown channels
- , watchChannelMessages dev channels
- , waitForSpecification
- >>| deviceTask (MTDevice dev sdsupdates channels)
- >>* [ifStable: issueShutdown]
- ]
+ parallel
+ [ channelSync spec channels
+ , watchForShutdown channels
+ , watchChannelMessages dev channels
+ , waitForSpecification
+ >>| deviceTask (MTDevice dev sdsupdates channels)
+ >>* [OnValue $ ifStable $ \_->issueShutdown]
+ ]
\end{lstClean}
If at any stage an unrecoverable device error occurs, an \gls{ITASK} exception is thrown in the \cleaninline{withDevice} task.
failover [] _ = throw "Exhausted device pool"
failover [d:ds] mtask = try (withDevice d (liftmTask mtask)) except
where except MTEUnexpectedDisconnect = failover ds mtask
- except _ = throw e
+ except e = throw e
\end{lstClean}
\section{Lifting mTask tasks}\label{sec:liftmtask}
\end{enumerate}
\begin{lstClean}[label={lst:liftmTask_pseudo},caption={Pseudocode implementation for \texttt{liftmTask}.}]
+liftmTask :: (Main (MTask BCInterpret a)) MTDevice -> Task a | iTask a
liftmTask task (MTDevice dev sdsupdates channels)
= freshTaskId dev
>>= \tid->withCleanupHook (sendmessage [MTTTaskDel tid] channels) (
compile task \mrefs msgs->
- sendMessage msgs channels
+ sendMessage msgs channels
>>| waitForReturnAndValue tid dev
-|| watchSharesDownstream mrefs tid sdsupdates
-|| watchSharesUpstream mrefs channels tid)
mtask :: (Shared sds Bool) -> Main (MTask v Bool)
| mtask, lowerSds v & RWShared sds
mtask sh =
- declarePin D13 PMOutput \d13->
+ declarePin D13 PMOutput \ledPin->
lowerSds \ls=sh
In fun \f=(\st->
getSds ls
- >>*. [IfValue (\v->v !=. st) (\v->writeD d13 v)]
- >>|. f (Not st))
- In {main=f true}
+ >>*. [IfValue (\v->v !=. st) (writeD ledPin)]
+ >>=. f)
+ In {main=getSds ls >>~. f}
\end{lstClean}
\section{Conclusion}
\newpage
\section{Home automation}
+\todo[inline]{Meer uitleg over de applicatie? ADT ipv strings voor keuze?}
This section presents an interactive home automation program (\cref{lst:example_home_automation}) to illustrate the integration of the \gls{MTASK} language and the \gls{ITASK} system.
It consists of a web interface for the user to control which tasks are executed on either one of two connected devices: an \gls{ARDUINO} UNO, connected via a serial port; and an ESP8266 based prototyping board called NodeMCU, connected via \gls{TCP}\slash{}\gls{WIFI}.
\Crefrange{lst:example:spec1}{lst:example:spec2} show the specification for the devices.
withShared False \sh->
liftmTask (lightswitch sh) dev
-|| updateSharedInformation [] sh <<@ Hint "Switch")/*\label{lst:example:ls2}*/
- , ("factorial", \dev->
+ , ("remote computation", \dev->
updateInformation [] 5 <<@ Hint "Factorial of what?"
>>? \i->liftmTask (factorial i) dev
>>- \r->viewInformation [] r <<@ Hint "Result" @! ())
\node (CN) [client,inner sep=0pt,draw,right=of CD] {Client\textsubscript{n}};
% line between server and browser
- \draw [dotted] ([xshift=-5em,yshift=-.8em]C1.south west) node[left,above]{browser} node[left,below]{server} -- ([xshift=5em,yshift=-.8em]CN.south east);
+ \draw [dotted] ([xshift=-5em,yshift=-.8em]C1.south west) node[left,above]{presentation} node[left,below]{application} -- ([xshift=5em,yshift=-.8em]CN.south east);
\node[task,inner sep=-4.5pt,below=of C1,fill=white,xshift=6.5em,yshift=-4.5em] (Tn) {Task\textsubscript{n}};
\node[task,inner sep=-4.5pt,below=of C1,fill=white,xshift=5em,yshift=-3.0em] (Td) {\ldots};
\node[fit={(T1)(Sn)},draw] (TS) {};
% line between client and server
- \draw [dotted] ([xshift=-5em,yshift=-11em]C1.south west) node[left,above]{server} node[left,below]{device} -- ([xshift=5em,yshift=-11em]CN.south east);
+ \draw [dotted] ([xshift=-5em,yshift=-11em]C1.south west) node[left,above]{application} node[left,below]{perception} -- ([xshift=5em,yshift=-11em]CN.south east);
% device 1
\node[task,text width=1.5em,inner sep=-4.5pt,node distance=12em,below=of C1,double copy shadow={shadow xshift=.4em,shadow yshift=-.4em},fill=white] (D1T1) {};
\node[draw,fit={(DNS1)(DNT1)([shift={(1.2em,-1.2em)}]DNS1.south east)},label=below:{\scriptsize mTask device\textsubscript{n}}] (DN) {};
% iTask server
- \node[fit={(C1)([shift={(1em,-1.2em)}]DN.south east)},draw,label={iTask server}] {};
+ \node[fit={(C1)([shift={(1em,-1.2em)}]DN.south east)},draw,label={IoT application}] {};
% Arrows
- \draw [<->] (C1) -- (T1);
- \draw [<->] (C2) -- (T1);
- \draw [<->] (CN) -- (T1);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (C1) -- (T1);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (C2) -- (T1);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (CN) -- (T1);
- \draw [<->] (T1) -- (S1);
- \draw [<->] (T1) -- (S2);
- \draw [<->] (T1) -- (Sn);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (T1) -- (S1);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (T1) -- (S2);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (T1) -- (Sn);
- \draw [<->] (Tn) -- node [midway,above,fill=white] {\texttt{liftmTask}} (D2T1);
- \draw [<->] (Sn) -- node [midway,above,fill=white] {\texttt{lowerSds}} (D2S1);
+ \draw [<->,shorten >=2pt] (Tn) -- node [midway,above,fill=white] {\texttt{liftmTask}} (D2T1);
+ \draw [<->,shorten >=2pt] (Sn) -- node [midway,above,fill=white] {\texttt{lowerSds}} (D2S1);
- \draw [<->] (D1T1) -- (D1S1);
- \draw [<->] (D2T1) -- (D2S1);
- \draw [<->] (DNT1) -- (DNS1);
+ \draw [<->,shorten <=4pt] (D1T1) -- (D1S1);
+ \draw [<->,shorten <=4pt] (D2T1) -- (D2S1);
+ \draw [<->,shorten <=4pt] (DNT1) -- (DNS1);
- \draw [<->] (D1.north) to [in=180,out=135] node [midway,above,fill=white] {\texttt{withDevice}} (TS.west);
+ \draw [<->,shorten <=2pt,shorten >=2pt] (D1.north) to [in=180,out=135] node [midway,above,fill=white] {\texttt{withDevice}} (TS.west);
\end{tikzpicture}
\end{document}
repositories / phd-thesis.git / commitdiff