Search

Reactive programming is a programming paradigm whereby programs are internally represented by a dependency graph, which is used to automatically (re)compute parts of a program whenever its input changes. In practice reactive programming can only be used for some parts of an application: a reactive program is usually embedded in an application that is still written in ordinary imperative languages such as JavaScript or Scala. In this paper we investigate this embedding and we distill "the awkward squad for reactive programming" as 3 concerns that are essential for real-world software development, but that do not fit within reactive programming. They are related to long lasting computations, side-effects, and the coordination between imperative and reactive code. To solve these issues we design a new programming model called the Actor-Reactor Model in which programs are split up in a number of actors and reactors. Actors and reactors enforce a strict separation of imperative and reactive code, and they can be composed via a number of composition operators that make use of data streams. We demonstrate the model via our own implementation in a language called Stella., LIPIcs, Vol. 166, 34th European Conference on Object-Oriented Programming (ECOOP 2020), pages 19:1-19:29

This artefact provides runnable versions of the code samples given in the main publication. An interpreter for the Stella language is provided together with a basic web-based IDE (syntax highlighting + running programs) which is able to run all Stella code given in the main publication. Also included are runnable implementations of the running example from the main publication (a simple wind turbine simulator) implemented in Stella and 6 other languages and frameworks (Akka, Flapjax, FrTime, ReactJS, REScala, and RxJS). While we do not discuss how these other technologies work, we highlight the interesting parts of the implementations of the running example: the difficulties we had, and any particular points of interest related to the claims made in the main publication., DARTS, Vol. 6, Special Issue of the 34th European Conference on Object-Oriented Programming (ECOOP 2020), pages 7:1-7:4

Many functions in libraries and APIs have the notion of optional parameters, which can be mapped onto optional properties of an object representing those parameters. The fact that properties are optional opens up the possibility for APIs and libraries to design a complex "dependency logic" between properties: for example, some properties may be mutually exclusive, some properties may depend on others, etc. Existing type systems are not strong enough to express such dependency logic, which can lead to the creation of invalid objects and accidental usage of absent properties. In this paper we propose TypeScriptIPC: a variant of TypeScript with a novel type system that enables programmers to express complex presence constraints on properties. We prove that it is sound with respect to enforcing complex dependency logic defined by the programmer when an object is created, modified or accessed.

Many programming languages, such as Clojure, Scala, and Haskell, support different concurrency models. In practice these models are often combined, however the semantics of the combinations are not always well-defined. In this paper, we study the combination of futures and Software Transactional Memory. Currently, futures created within a transaction cannot access the transactional state safely, violating the serializability of the transactions and leading to undesired behavior. We define transactional tasks: a construct that allows futures to be created in transactions. Transactional tasks allow the parallelism in a transaction to be exploited, while providing safe access to the state of their encapsulating transaction. We show that transactional tasks have several useful properties: they are coordinated, they maintain serializability, and they do not introduce non-determinism. As such, transactional tasks combine futures and Software Transactional Memory, allowing the potential parallelism of a program to be fully exploited, while preserving the properties of the separate models where possible.

We propose the localised ρ-calculus, a process calculus that uses an identification of processes and names in higher-order communication along with a notion of locations. These are named, bounded areas for computation, organised in a hierarchy, and processes can move from one to another by crossing their boundaries. Process migration becomes higher-order communication. To control the usage of channels we develop a type system with binary session types for the localised ρ-calculus, based on work by Giunti and Vasconcelos, and prove that it is sound.