Writing Internet of Things Applications with Task Oriented Programming

Abstract

The Internet of Things (IoT) is growing fast. In 2018, there was approximately one connected device per person on earth and the number has been growing ever since. The devices interact with the environment via different modalities at the same time using sensors and actuators making the programs parallel. Yet, writing this type of programs is difficult because the devices have little computation power and memory, the platforms are heterogeneous and the languages are low level. Task Oriented Programming (TOP) is a declarative programming language paradigm that is used to express coordination of work, collaboration of users and systems, the distribution of shared data and the human-computer interaction. The mTask language is a specialized, yet full-fledged, multi-backend TOP language for IoT devices. With the bytecode interpretation backend and the integration with iTask, tasks can be executed on the device dynamically. This means that—according to the current state of affairs—tasks can be tailor-made at run time, compiled to device-agnostic bytecode and shipped to the device for interpretation. Tasks sent to the device are fully integrated in iTask to allow every form of interaction with the tasks such as observation of the task value and interaction with Shared Data Sources (SDSs). The entire IoT application—both server and devices—are programmed in a single language, albeit using two embedded Domain Specific Languages (EDSLs).

Appendices

A Embedded Domain Specific Language Techniques

An EDSL is a language embedded in a host language created for a specific domain [23]. EDSLs can have one or more backends or views. Commonly used views are pretty printing, compiling, simulating, verifying and proving the program. There are several techniques available for creating EDSLs. They all have their own advantages and disadvantages in terms of extendability, type safety and view support. In the following subsections each of the main techniques are briefly explained. An example expression DSL is used as a running example.

1.1 A.1 Deep Embedding

A deeply EDSL is a language represented as data in the host language. Views are functions that transform something to the datatype or the other way around. Definition 20 shows an example implementation for the expression DSL.

Deep embedding has the advantage that it is easy to build and views are easy to add. On the downside, the expressions created with this language are not necessarily type-safe. In the given language it is possible to create an expression such as Plus (LitI 4) (LitB True) that adds a boolean to an integer. Extending the Algebraic Datatype (ADT) is easy and convenient but extending the views accordingly is tedious since it has to be done individually for all views.

The first downside of this type of EDSL can be overcome by using Generalized ADTs (GADTs) [11]. Example 21 shows the same language, but type-safe with a GADT. GADTs are not supported in the current version of Clean and therefore the syntax is hypothetical. However, it has been shown that GADTs can be simulated using bimaps or projection pairs [11]. Unfortunately the lack of extendability remains a problem. If a language construct is added, no compile time guarantee can be given that all views support it.

1.2 A.2 Shallow Embedding

In a shallowly EDSL all language constructs are expressed as functions in the host language. An evaluator view for the example language then can be implemented as the code shown in Definition 22. Note that much of the internals of the language can be hidden using monads.

The advantage of shallowly embedding a language in a host language is its extendability. It is very easy to add functionality because the compile time checks of the host language guarantee whether or not the functionality is available when used. Moreover, the language is type safe as it is directly typed in the host language, i.e. Lit True +. Lit 4 is rejected.

The downside of this method is extending the language with views. It is nearly impossible to add views to a shallowly embedded language. The only way of achieving this is by reimplementing all functions so that they run all backends at the same time. This will mean that every component will have to implement all views rendering it slow for multiple views and complex to implement.

B iTask reference

This appendix gives a brief overview of iTask. It is by far extensive but should cover all iTask constructions required for the exercises. Some examples from [45] can be found in Sect. B.6.

1.1 B.1 Types

The class collection iTask is used throughout the library to make sure the types used have all the required machinery for iTask. This class collection contains only generic functions that can automatically be derived for any first order user defined type. Example 23 shows how to derive this class.

1.2 B.2 Editors

The most common basic tasks are editors for entering, viewing or update information. For the three basic editors there are three corresponding functions to create tasks as seen in Definition 23.

The first argument of the function is something implementing toPrompt. There are toPrompt instances for at least String—for a description, (String, String)—for a title and a description and ()—for no description.

The second argument is a list of options for modifying the editor behaviour. This list is either empty or contains exactly one item. The types for the options are shown in Definition 24. Simple lenses are created using the *As constructor. If an entirely different editor must be used, the *Using constructors can be used.

Example 24 shows an example of such an editor using a lens. The user enters a temperature in degrees Celsius and the editor automatically converts the result to a temperature in Fahrenheit which is in turn the observed task value.

1.3 B.3 Task Combinators

There are two flavours of task combinators, namely parallel and sequential that are all specializations of their Swiss-army knife combinator step and parallel respectively.

Parallel Combinators. The two main parallel combinators are the conjunction and disjunction combinators shown in Definition 25.

The - &&- has semantics similar to the mTask . &&. combinator. The -||- has the same semantics as the mTask .||. combinator. The -|| and ||- executes both tasks in parallel but only looks at the value of the left task or the right task respectively.

Example 25 shows an example of a task that, using the disjunction combinator, asks the user for a temperature either in degrees Celsius or Fahrenheit using the task from Example 24. Whichever editor the user edits last, will be the observable task value.

Sequential Combinators. All sequential combinators are derived from the $\texttt {>>*}$ combinator as shown in Definition 26. With this combinator, the task value of the left-hand side can be observed and execution continues with the right-hand side if one of the continuations yields a Just (Task b). The listing also shows many utility functions for defining task steps.

Example 26 shows an example of the step combinator that forces the user to enter a number between 0 and 10. If the user enters a different value, the continue button will remain disabled.

Derived from the $\texttt {>>*}$ combinator are all other sequential combinators such as the ones listed in Definition 27 with their respective documentation.

1.4 B.4 Shared Data Sources

Data can be observer via task values but for unrelated tasks to share data, SDSs are used. There is an publish subscribe system powering the SDS system that makes sure tasks are only rewritten when activity has taken place in the SDS. There are many types of SDSs such as lenses, sources and combinators. As long as they implement the RWShared class collection, you can use them as an SDS. Definition 28 shows two methods for creating an SDS, they both yield a SimpleSDSLens but they can be used by any task using an SDS.

With the sharedStore function, a named SDS can be created that acts as a well-typed global variable. withShared is used to create an anonymous local SDS.

There are four major operations that can be done on SDSs that are all atomic (see Definition 29). get fetches the value from the SDS and yields it as a stable value. set writes the given value to the SDS and yields it as a stable value. upd applies an update function to the SDS and returns the written value as a stable value. watch continuously emits the value of the SDS as an unstable task value. The implementation uses a publish subscribe system to evaluate the watch task only when the value of the SDS changes.

For all editors, there are shared variants available as shown in Definition 27. This allows a user to interact with the SDS.

1.5 B.5 Extra Task Combinators

Not all workflow patterns can be described using only the derived combinators. Therefore, some other task combinators have been invented that are not truly sequential nor truly parallel. Definition 31 shows some combinators that might be useful in the exercises.

1.6 B.6 Examples

Some workflow task patterns can easily be created using the builtin combinator as shown in Examples 28.

C How to Install

This section will give detailed instructions on how to install mTask on your system. The distribution used also includes the example skeletons.

1.1 C.1 Fetch the CEFP distribution

Download the CEFP version of mTask distribution for your operating system as given in Table 2 and decompress the archive. The archives is all you need since it contains a complete clean distribution. The windows version contains an IDE and Clean Project Manager (cpm). Mac and Linux only have a project manager called cpm.

Table 2. Download links for the CEFP builds of mTask.

1.2 C.2 Setup

Linux. Assuming you uncompressed the archive in , run the following commands in a terminal.

Windows. You do not need to setup anything on windows. However, if you want to use cpm as well, you need to add the to your %PATH%⁷.

MacOS. Assuming you uncompressed the archive in , run the following commands in a terminal.

1.3 C.3 Compile the Test Program

Note that the first time compiling everything can take a while and will consume quite some memory.

Windows. Assuming you uncompressed the archive in . Connect a device or start the local TCP client by executing

IDE

• Open the IDE by starting .

• Click on or press ond open .

• Click on or press .

cpm Enter the following commands in a command prompt or PowerShell session:

Linux & MacOS. Assuming you uncompressed the archive in . Connect a device or start the local TCP client by executing . In a terminal enter the following commands:

1.4 C.4 Setup the Microcontroller Unit

For setting up the RTS for the MCU, the reader is kindly referred to here⁸.

D Solutions