In this article I'll try to show how to implement a basic Scala compiler plug-in. My starting point is this excellent article from Lex Spoon which provides the main information required to understand how compiler plug-ins work. It gives a simple example: a static code checker that raises compilation errors as soon as a division by zero occurs (division by the constant 0).

A compiler plug-in is some Scala code that can be injected as a specific phase of the compilation process of a given project and that allows you to access to the Abstract Syntax Tree (AST) corresponding to the Scala source code that is being compiled. Then it's a matter of matching the proper patterns, raise erros and warnings and, if needed, transform the AST (this, I did not try so far...).

Our goal in this article is to implement the so called "mutable-phobia" plug-in which raises errors as soon as a var definition gets detected !!!
Here is step by step how to do this:

Imagine that you want to proceed any instance or object that realizes a given contract i.e. that implements a given set of specific methods. The classical approach tells you to create a new abstraction (an Interface in Java, a Trait in Scala) that provides all the required method signatures. For instance:

/**
 * Using a trait
 */

trait Omnipotent {
  def doThis: String
  def doThat: String
}

def doEverything(o: Omnipotent) = {
  println(o.doThis)
  println(o.doThat)
}

object deity extends Omnipotent {
  def doThis: String = "This is done !!"
  def doThat: String = "That is done !!"
  def doTheRest: String = "Everything's done!!"
}

doEverything(deity)

Now, if you want to do the same thing without defining any additional trait, you can use a type definition instead:

/**
 * Using a type
 */

type Omnipotent = {
  def doThis: String
  def doThat: String
}

def doEverything(o : Omnipotent) = {
  println(o.doThis)
  println(o.doThat)
}

object deity {
  def doThis: String = "This is done !!"
  def doThat: String = "That is done !!"
  def doTheRest: String = "Everything's done!!"
}

doEverything(deity)

Compared to the previous example, the most important difference here is that the deity object doesn't extend anything, but is explicitly of type Omnipotent.

Scala has been designed to enable the implementation of Domain Specific Languages. This is surely one of its major strength (see DSLs – A powerfull Scala feature for more information).

This article is an attempt to develop a very simple internal DSL dealing with the X10 home automation protocol (as done here on the top of Oslo).

Here is the syntax (not sure that it reflects exactly the X10 protocol, but it's enough for our example ...):

• on [house_code] [unit_code]
  where [house_code] is a letter between A and P (16 values) and [unit_code] an integer between 1 and 16 or All (for any devices).
• Idem for the off command
• It's the same for bright and dim commands except that an additional level parameter is required:
  bright A 12 level 80

Announced by Google this week: the Java App Engine is now available. It comes with a new eclipse plugin that allows to manage both the deployment on the App Engine and application development using GWT (version 1.6).
The first obvious question for a Scala Dude is: What about the Scala integration ?
A first answer can be found directly from the google-appengine-java group:

• Scala works out of the box.
• Scala Actors do not work, because they are implemented using Threads (which are not supported).
• The Lift web framework does not work out of the box, because it depends on Actors and JDBC.

Some blogs confirming the limitations listed above:

• print "Me"
• Froth & Java
• Mawson's Hut
• Pinky (Scala REST/MVC web framework)

So it's not perfect, but it's good news for the Scala eco-system anyway !!
Note that it seems that Lift will work on the Java App Engine soon (see the comment from David Pollak: "I'll get code checked up next week that makes core Lift work with gae") ...

As mentioned in my previous article about the Proxy design pattern, the ability to add features to an existing abstraction without involving an explicit extension of this abstraction is basically the purpose of the Decorator design pattern.
So, this article is simply a recap of the way to implement a Decorator using the technique based on implicit conversion.