print · login   

Theme: Internet of Things, Task Oriented, Functional, and Tierless Programming

Task-Oriented Programming (TOP) is a new programming paradigm for developing interactive multi-user systems, developed by our department. As its name suggests, this programming paradigm uses Tasks as the central concept. A task is a piece of work that corresponds to its equivalent in everyday life. Such a task has an observable intermediate value. The value of a task can change after a rewrite step initiated by an event. (for this topic contact Mart Lubbers or Peter Achten)

A TOP framework provides :

  • A set of primitive tasks (like editors in a web page and sensors);
  • A set of task combinators to compose tasks;
  • A way to define data sources used for task communication;
  • A set of data source combinators;
  • A task execution engine.

The iTask system is an implementation of TOP in the functional programming language Clean. This embedded DSL uses generic programming to generate as much as possible based on the type definitions of data involved. Generics are for instance used to create web-based editors for the data types used in the interaction with humans. Whenever desired the programmer can always replace the generated parts by tailor-made version. The iTask system is also used in industry by for example TOP Software, see Collaboration with the Industry for theses and internship projects at this company.

The mTask system is an embedded DSL to port TOP to the IoT. The Internet of Things, IoT, is mainly driven by cheap and energy-efficient microcontrollers that are not powerful enough to execute full-blown iTask programs. By imposing constraints on the data-types and manipulations allowed TOP programs in mTask can be executed by IoT devices. Since iTask and mTask program components can be united seamlessly into a single source the usual update and communication problems for communication between the IoT devices and their server are eliminated.

Although these TOP systems work pretty well, there are many wishes, possible improvements and open problems. A nonexhaustive list contains:

General Task-Oriented Programming topics (contact: Peter Achten, Mart Lubbers, Pieter Koopman)

  1. More real-life multi-platform (arm/intel) applications (e.g. an Uber-like application with tracking of positions and interactions).
  2. More real-life IoT applications made with the iTask/mTask system.
  3. Integration in existing systems (like email, standard web pages) with the current iTask system.
  4. The current iTask system works very well with browsers. It is desirable to extend this interaction in a generic way to smart-phones and smart-watches.
  5. Currently mTask and iTask programs are created in traditional programming environments (either an IDE or a command-line based system). It would be convenient to create and execute such programs in a web browser without requiring the installation of any special software.
  6. The graphical construction of TOP Applications by drag and drop for non-programmers. Preferably this works also in a browser instead of some environment that requires software installation.
  7. Support for tasks and data sources that live longer than their current definition. Sometimes it is convenient to change running task or update data-type during task execution. In a dynamically typed system those kind of updates are easy. Here we want to do this in a statically types system where the type system still prevents runtime type problems.
  8. To test new versions of the iTask system or new versions of a specific iTask application, it would be very convenient to rerun a previous task with capture and play-back, or via some script.
  9. To monitor task execution and debug tasks it is convenient to enable graphical views and dynamic tracing of task execution.
  10. We have an example editor for tasks based on a concept of dynamic editors. There are however still some features lacking and many possible extensions. For a sufficiently powerful task editor, we still lack the power to introduce typed variables in the user editor. Possible extensions would be more sufficient checks on the editor values, e.g. tasks obeying resource constraints.
  11. The current concept of SDS is based on the idea of having a state. In many real world applications however data sources provide streams of data. Modelling this as state (a list of values) will probably never give the performance required to handle streams with hundreds of data items per second. Such stream can however straightforwardly be handled by message brokers such as RabbitMQ. How can we extend the concept of SDS to handle such streams as well?
  12. We currently use properties in definition modules as documentation with formal meaning as well as for automatically generating tests (https://gitlab.com/clean-and-itasks/clean-test-properties). Can this concept be extended for tasks as well?

b) Tierless programming and Internet of Things (contact: Mart Lubbers and Pieter Koopman)

  1. Enable IoT devices to produce their own web page to monitor their status and progress.
  2. Analyse and improve the security of mTask based IoT programs.
  3. The mTask system is excellent to control power consumers (like light bulbs and heaters) in the real world. We would like to reason about the power consumption by abstract interpretation or symbolic computation.
  4. Extend the support for green energy in mTask to reduce the power consumption of IoT devices and their communication.
  5. All communication between various IoT devices goes currently via the server. Sometimes it is desirable to have direct device-device communication and/or to create a mesh network.
  6. There is a formal semantics for a TOP language similar to mTask (TopHAT). We would like to port this to mTask and to use it to support proving properties of programs.
  7. The TOP paradigm is unrelated to Clean. However, the iTask and mTask systems exploit all of the possibilities of Clean to create expressive and typesafe DSLs. It is interesting to investigate how the TOP concepts can be ported to other programming languages like Scala, Kotlin or Haskell.
  8. Many TOP systems have some kind of exception handling, we would like to investigate this for mTask as well.
  9. Data types in mTask must have a size known at compile time. More complex data structures like lists, records or arrays would be a useful addition that comes with many interesting research questions.
  10. Intermittent computing is the idea that when the power drops, the systems shuts down. Once the power resumes, the system continues where it left off. This is quite complex for programs in general but for TOP this should be quite natural (due to the discrete rewrite steps) and we would like to realise this.
  11. mTask (and TopHAT for that matter) are less expressive than iTask. There are many workflow-like benchmark suites that could reveal the gaps in expressivity (e.g. v.d. Aalst workflow benchmark).

c) Collaboration with the Industry (contact: Mart Lubbers)

WebAssembly Code Generation for a Purely Functional Language

It is essential to run Clean code in browsers efficiently, to realise a powerful task-oriented programming framework (iTasks). For this currently an interpreter is employed, written in WebAssembly (https://gitlab.com/clean-and-itasks/abc-interpreter). Such interpreter can naturally not achieve the same efficiency as a solution translating to WebAssembly directly.

There are ongoing efforts to realise a code generator translating Clean's intermediate language ABC to LLVM bitcode. From this, code for arbitrary targets, including WebAssembly, can be generated.

There are numerous possible projects for the different aspects of such code generator:

  1. How can the ABC machine and ABC instructions be represented in LLVM in a convenient and efficient way?
  2. Does Clean's native code generator employ any Clean specific optimisations, which would have to be incorporated into an LLVM code generator?
  3. How does the performance of Clean code translated to WebAssembly compare to code interpreted by the WebAssembly interpreter?
  4. How does x86/x64 code generated by the LLVM toolchain compare to code generated by Clean's native code generator?

Evaluating iTasks Tasks in the Browser

Task-oriented programming (TOP) provides a neat paradigm to specify and implement web-applications coordinating the work of multiple users and software systems. A drawback of the current implementation (iTasks) is that each user action on the client (browser) has to be communicated to the server, which then generates a UI update for the client. In case of large UI updates (e.g. drawing a large number of objects on a map) or many concurrent users, this results in a high load of the server, high network traffic and delays of UI updates. It therefore hinders deploying task-oriented applications for a large number of concurrent users.

There have been recent efforts to specify effects of tasks more explicitly, with the goal of enabling to evaluate parts of the task-tree on other nodes. The next step is to explore ways to realise and implement evaluation of tasks in the browser. For this, clients have to run a task event loop, translating effects (e.g. operations on data sources), which have to be performed on the server. This includes answering the following questions:

  1. How can the event loop for evaluating tasks, written in the functional language Clean, be adapted to run in the browser?
  2. How can effects triggered by events of tasks running in the browser be translated to be performed on the server?
  3. How does the implementation perform? Are there any limitations on the size and complexity of tasks running in the browser?
  4. How much does the approach improve scalability of iTasks application? Can we indeed support a higher number of concurrent users when moving parts of the task computations to the client?

Improve Usability of Dynamic Editors

Dynamic editors (paper, source) aim to bridge the gap between human domain experts and computer systems. They allow to enter expressions in the language of domain experts, but still in a structured and type-safe manner. Such editors are used in commercial applications to provide a DSL to domain experts (https://www.top-software.nl/VIIA.html). The implementation is based on advanced dynamic type-system features of the functional language Clean.

An example of a generated UI for a data type using dynamic editors
An example the generated UI for such an editor

The dynamic editors are already successfully being used in production environments. However, their usability is still not optimal. There are several ways in which such editors could be made more user friendly, based on feedback from real users. Possible questions to answer are:

  1. How can the text generated for the UI be made more understandable to human users? (One aspect is to generate more correct natural language, e.g. sentences with correct grammar.)
  2. How can we make adapting existing expressions more user-friendly? (An example would be to change the "AND" to an "OR" in the above screenshot, without re-entering the entire expression about positions and speeds.) Can already defined sub-expressions be reused in a user-friendly way?