Angular shitstorm: What's your opinion on the controversial plans for Angular 2.0?
Oz Concurrency Comes to Scala

Ozma: Bringing Declarative Concurrency to Scala

Jessica Thornsby

Ozma creator Sébastien Doeraene talks about bringing Oz’s concurrency to the Scala language.

Ozma is a new Scala extension that adds concurrency from the Oz multi-paradigm language. It compiles to its own Mozart virtual machine, and is available from GitHub. In this interview, JAXenter speaks to Ozma creator Sébastien Doerae, on the release of Ozma, and why the Scala world needs Oz’s concurrency.

JAXenter: Can you give us an introduction to the Ozma project?

Sébastien Doeraene: Ozma is a conservative extension to Scala with Oz concurrency. It adds the concurrency idioms of Mozart Oz to the Scala language.

Oz is a multi-paradigm language that has strong support for concurrent and distributed programming. It compiles to its own virtual machine – called Mozart – that supports dataflow synchronization and lightweight threads.

Ozma is an attempt at making the great features of Oz concurrency available to a larger public. It has the syntax and the type-system of Scala, but runs on the Mozart VM.

JAXenter: What technologies are at work in Ozma?

Sébastien: The compiler is written in Scala, and is based on the official Scala compiler. The runtime engine is written in Oz, and is based on the Mozart VM. Additionally, we use Ant for the build process.

JAXenter: What benefits does Ozma add, for the Scala user?

Sébastien: Ozma adds the following features to Scala: tail call optimization of functions that are tail-recursive modulo cons, lightweight threads, dataflow variables (known as dataflow values in Ozma), lazy execution, and message-passing concurrency with ports. For a short introduction to these concepts, see section 3.2 of the text of the master’s thesis.

The main benefit of Ozma is that it introduces *declarative concurrency*. This model of concurrency is very important: it makes concurrency *deterministic*. It eases considerably the development of concurrent programs, because we can reason about the program as if it were sequential.

In classical concurrency models, we always use shared state concurrency. This model is difficult to work with because the developer has to pay attention to all possible interleavings of threads. With declarative concurrency, there is no need to do that.

Deterministic models are important for non-deterministic problems too: subcomponents can be written in a declarative, deterministic style. Such components are easier to reason about, and can be composed in a concurrent way with no effort.

JAXenter: How does Ozma relate to Scala’s existing concurrency model?

Sébastien: Scala has two well-known concurrency models: shared state concurrency, inherited from Java, and the actor model provided by Akka. In both cases, the program has to be written with concurrency in mind. Ozma uses declarative concurrency, built into the language. Depending on the application, a different model will be more appropriate.

JAXenter: Can you give us some potential use cases for Ozma?

Sébastien: As soon as a software component expresses itself naturally in a concurrent way, Ozma helps the developer because it provides effortless concurrency. A game, for example, often consists of several mobs and players that interact with the field they walk on and with each other. All these agents are naturally concurrent.

JAXenter: What challenges did you face, in extending Scala with concurrency features from Oz?

Sébastien: Well, the work as a whole was a challenge! Thanks to the incredible modularity of the Scala compiler, I did not face any technical issue regarding the implementation of the compiler.

The biggest challenge was to design the language, with built in dataflow values, so that it was both a) conservative and b) elegant.

a) Scala is a very complex language. Changing the semantics of any mere *val* without altering the global semantics of existing programs had to be carefully thought out.
b) Scala is an elegant language. The features I added needed to be introduced in an equally elegant way.

I personally think I was successful!

JAXenter: What are the next potential steps, for Ozma?

Sébastien: First, there are still some technicalities that need to be addressed. Ozma does not have separate compilation yet, for example. The major issue is the lack of support of the Java standard library. Extending the set of available classes is an important work, that is still in progress. Basically we need to reimplement the Java library in Scala! A discussion was started today on scala-internals on how to factor out this work, so that me and other back-end developers (e.g. Scala-LLVM) need not reimplement it all over again.

In the long term, we will have to integrate the distribution system of Mozart Oz in Ozma. Oz supports fault-tolerant network transparency. Making this available in Ozma as elegantly as the concurrent features I already introduced will be an exciting research topic!

comments powered by Disqus