Theme: Task Oriented and Functional 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 Pieter Koopman 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 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:
- More real-life multi-platform (arm/intel) applications (e.g. an Uber-like application with tracking of positions and interactions).
- More real-life IoT applications made with the iTask/mTask system.
- Integration in existing systems (like email, standard web pages) with the current iTask system.
- The current iTaks system works very well with browsers. It is desirable to extend this interaction in a generic way to smart-phones and smart-watches.
- 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.
- 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.
- 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.
- 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.
- To monitor task execution and debug tasks it is convenient to enable graphical views and dynamic tracing of task execution.
- Enable devices with internet access to produce their own web page to monitor their status and progress.
- Analyse and improve the security of mTask based IoT programs.
- 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.
- Extend the support for green energy in mTask to reduce the power consumption of IoT devices and their communication.
- 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.
- There is a basic semantics for TOP. It is desirable to extend this to cover a bigger part of iTask/mTask and to use it to support proving properties of programs.
- 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.
- 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.
- 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?
- We currently use properties in definition modules as documentation with formal meaning as well as for automatically generating tests (https://gitlab.science.ru.nl/clean-and-itasks/clean-test-properties). Can this concept be extended for tasks as well?
