Join definitions in Scala

The experimental feature of Scala described in this document allows to define simultaneously a set of functions (or methods) by giving a set of rules that specify synchronization patterns like in the join-calculus.

It is implemented as an extra phase of the compiler (between the parser and the typechecker) that transforms join definitions into normal definitions of functions that use Scala concurrent primitives (inherited from Java) to synchronize together. This phase is enabled by giving the option -join to the Scala compiler socos.

Note that the presented feature is NOT part of the current version of the Scala compiler.

Commented example

  class Reference[a](init: a) with {

    module join with {
      def get: a;
      def set(x: a): Unit;
      private def state(x: a): nil;

      get & state(x) = spawn < (reply (x) to get) | state(x) >;
      set(x) & state(y) = spawn < (reply to set) | state(x) >;
    }
    state(init);
  }

• The join definition is delimited by the construct module join with { ... }. It is a fixed construct, i.e. join is a new Scala keyword when the join phase is enabled.
• It defines three methods get, set and state.
• Methods are declared in the first part of the definition by giving them a type. Methods get and set are synchronous (wait for a result when called) and have a standard Scala result type. Method state is asynchronous, so it must be given the special return type nil.
• Methods get and set are respectively used to read and write the value stored in the reference. The asynchronous method state is used to keep the value. It is declared private because it is not part of the interface.
• The second part of the join definition consists of a set of rules. The left-hand side of a rule specifies the functions that have to be waiting for a result in order to trigger the rule. Notice that function parameters must not be annotated with types. The right-hand side of the rule can be any Scala expression of type Unit and will be executed in a new thread as soon as the rule is triggered, in a environment where formal parameters of functions in the left-hand side of the rule will be binded to the actual arguments of the calls.
• The construct spawn< e1 | ... | en > is not a new construct. It corresponds to the call of the function spawn defined in the module concurrency and is used to execute several threads (any Scala expression of type Unit) in parallel.
• The construct reply (e) to f is used to give a result (the result of the evaluation of expression e to the function f. reply to f is just syntactic sugar for reply (()) to f.
• The function call state(init) is located outside the join definition. It is used to store the initial value in the reference and shows that methods (or functions) defined in a join definition are used as any other Scala function. After translation each function defined in the block "module join with { ... }" becomes a method of the enclosing class or module. So it is completely valid to call state inside the class, even if it was declared private.

Remarks

• In this example we defined some methods of an class using a join definition. But if we want to define functions of a block, we have to use the construct join { ... } instead of module join with { ... }.
• The file Reference.join contains the result of the transformation.
• It is completely valid to override in a subclass a method participating in a join, but it will not be able anymore to synchronize with the functions defined in the initial join definition.

Other examples

• The definition of synchronous channels in join-calculus: (SynChan.scala).
• The definition of a semaphore in join-calculus: (Semaphore.scala).
• The definition of references using join-calculus: (Reference.scala).
• An implementation of the parallel or: (parallelOr.scala).
• A solution to the reader/writer problem expressed in join-calculus: (ReaderWriter.scala).

Contact

References

Join-patterns are the concurrency primitives of the join-calculus. They were the basis of Funnel, a small programming language based on Functional Nets which can be seen as a uniform foundation for programming based on join-calculus. Join-patterns in Scala are used quite the same way there were used in Funnel, namely channels defined in a join-definition are seen as functions or methods of an object. The calls to these methods are synchronized according to the join-pattern.

The compilation of join-patterns made in this implementation is based on the one for jocaml described in the following paper: Compiling Join-Patterns, by Fabrice Le Fessant and Luc Maranget, HLCL'98.