## Video: The Scala Experiment

An hour long presentation by Martin Odersky on The Scala Experiment is available on Google Video. Covers a lot of territory, including (naturally) integration of FP/OOP, Erlang style Actors, Components vs. APIs, ML Functors, mixins, self-types - to name a few. The video is fuzzy on the slides, so it helps to have the pdf of the slides handy.

I can't say that I groked all the implications of the ground covered, much less the exact syntax, but at least it gave me a better feel for some of the PL problems that the Scala project is trying to address.

## Comment viewing options

### A second recommendation

Thanks for the excellent link, Chris.

I have to second this recommendation. Anyone interested in Scala or in the design space it covers (OO/FP blend) will probably get a lot out of it.

(Wouldn't have minded fewer nerdy questions from the audience though ;-))

Well worth the hour's attention.

### Specifying component requirements

I agree that the questions from the audience were a bit distracting, particularly since it was so hard to hear them with all the ambient noise.

One question that a member of the audience had was in regard to Martin's claim that traditional OO language support doesn't go far enough to enable components. He said that interfaces allow you to specify the services a component provides, but not what a component requires. His answer seemed to handwave a bit; I'm still uncertain.

Say we define a class C whose constructor takes a parameter with interface R and implements the interface I. In other words, in Java-ese:

class C implements I { public C(R r) { ... } }

If we declare "C" to be a component, it seems to me that the interface "R" specifies the services the component requires, and "I" specifies the services it provides. If we think of both "R" and "C" as modules, this seems to be close to the idea of functors, with the exception that (in Java, at least), I and R cannot specify types.

What is it about "components" that requires more of the language than this? I'm guessing the abstract types have something to do with it, but I still don't quite get it.

I really enjoyed this video. Kudos to Martin and his team for a valiant effort at unifying OO and FP, and breaking new ground in the process.

### The right track...

I haven't watched the video yet, so don't know how well Odersky addressed the question in the talk. But you're right in guessing that there's a bit more to Scala's support for components than Java-style interfaces, and you're right that abstract types have something to do with it. I highly recommend Scalable Component Abstractions. I think you'll find the presentation clear and the examples quite compelling.

### Explicit self types to express requirements

Let me take a quick stab at giving you an intuition as to how Scala provides support for specifying a component's required interface:

When you specify a class, you may also specify the type of the this variable using the requires keyword (when you don't specify it, it's simply the defining class itself.)

So, suppose you have a component MessageBroker, that depends on a Transport component, you may specify it like this:

class MessageBroker requires (MessageBroker with Transport)

The effect of this definition is that this will be of the compound type MessageBroker with Transport in the body of MessageBroker.

This is similar to directly extending a concrete implementation of Transport, in that members from Transport will be available on this in your message broker. However, it is more flexible than inheritance, as it allows you to defer the choice of which concrete Transport you want until you actually instantiate MessageBroker. In other words, Transport need not be a concrete class (so you can use abstract type members to make this even more flexible).

So, to instantiate a MessageBroker with a HTTPTransport, you write new MessageBroker with HTTPTransport.

### Constructors and functors

It's true, class constructors can express required components as interface-typed parameters. However, this runs into problems for more complex compositions.

One problem is that diamond dependencies cannot be expressed. I.e. class A requires B and C, but also requires that B and C agree on the type of one of their components. This problem is solved by abstract types in Scala and by sharing constraints in ML.

Another problem is that recursive dependencies cannot be expressed through parameterization. This problem is also present in the SML module system. It is solved in Scala through mixin composition.

### component requirements

Here's my best guess on the component requirements issue. In Scala you can define a trait like this:

trait LabelProvider requires LabelComponent {
...
}

class MyLabel extends LabelComponent with LabelProvider {
}

LabelProvider isn't just an interface. It can provide implementations of methods. With the "requires" in place it can do more -- it "knows" that when made concrete it's going to have LabelComponent amongst its base types, so it is free to call methods in LabelComponent's scope in its own method implementations.

The Scala compiler uses this pretty extensively to sew together an extensive fabric of componentry.