Oz Concurrency Comes to Scala

Ozma: Bringing Declarative Concurrency to Scala

Jessica Thornsby
Ozma-Bringing-Declarative-Concurrency-to-Scala

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!

Author
Comments
comments powered by Disqus