First of all, Akka is likely to support what Ray Racine has coined to be a ‘System of Service’. I’m quoting him here literally from the scala mailing list:

Its not too far of stretch to say commercial vendors, and most frameworks are very System Of Record oriented. Need to build a new app to maintain X.
Install RDB, app server, select O/R mapping and GUI form framework, place warm bodies in front of drag and drop IDEs and go for it.

A System Of Service must service 1,000s of requests per second in millisecs, 24/7/365 with 99.99 % reliability e.g. a pricing service. The business
logic has to run in microseconds. Your favorite O/R mapping framework hasn’t even initiated a JDBC call, heck hasn’t even allocated a connection from the pool and its already exhausted its 1 ms in allotted time.

An item may undergo a few 10s of price changes a year on the System Of Record, yet that item’s price may be served 100,000 times for each change on the System Of Service’.

In other words a System of Service is a system designed to have extreme throughput, and almost zero downtime. It may not be your everyday CRUD application, but if you need to build them, it is nice to know of some framework that supports it. In response to Ray Racine’s post Jonas Bonér posted his vision for the Akka framework. These posts provide plenty of highly interesting reading material, and can be found here.

Akka is therefore meant to be a kind of framework that supports a System Of Service application. It has many features, too much to cover all at once, and therefore we will start of with having a look at Akka’s actors supervisor capabilities.
Akka has an Actor model with supervision trees, based on Erlang’s OTP design principles. Supervisors are processes that monitor a set of workers, that do the actual processing. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary. A worker is an Actor, that receives and processes a message. When a worker dies abnormally (by throwing an Exception), it is up to the supervisor to determine what to do. It may decide to restart the worker, and try to process the message again, with a maximum number of retries set. The approach is to expect that failures can and eventually will happen. Instead of trying to prevent this, the idea is to Let it crash (TM Jonas Bonér), reset the worker to a stable state, restart it. This idea has served Ericsson well in building highly fault tolerant, distributed message passing software. We can now profit from this idea in Scala as well via Akka.

In order to achieve this, Akka has its own version of the Actors library, that have more ‘system of service’ features than the standard Actors library found in the Scala distribution. To demonstrate a simple example of a supervisor class, here’s some sample code to demonstrate the idea. First, we start of with a simple Actor:

import se.scalablesolutions.akka.config.ScalaConfig._
import se.scalablesolutions.akka.actor.{OneForOneStrategy, Actor}

sealed trait Message

case class Supervise(worker: Worker) extends Message

case class DoWork(work: Work) extends Message

case object Die extends Message

class Worker(workerName:String) extends Actor {
lifeCycleConfig = Some(LifeCycle(Permanent, 100))

def receive: PartialFunction[Any, Unit] = {

case DoWork(work:String) =>
log.debug("start working... at: " + work)

case Reset =>
log.info("%s has been reset", toString)

case Die =>
log.debug("Dying...")
throw new RuntimeException("I'm dead: " + this.toString)

case other =>
log.error("Unknown event: %s", other)
}

override def preRestart(reason: AnyRef, config: Option[AnyRef]) {
log.debug("pre-restarting " + this)
}

override def postRestart(reason: AnyRef, config: Option[AnyRef]) {
log.debug("post-restarting " + this)
}

override def toString = "[" + workerName + "]"

As regards to sending message passing, an Akka actor follows the same API as the ‘normal’ Scala ones: you can send a message to an actor using the ! (pronounced bang) method. This is a ‘fire and forget’ message, which is then processed asynchronously by the actor. There are some more options to send messages, but we’ll skip these for now. In Akka, Actors have to be started explicitly by calling actor.start for it to be able to process any messages. It can be stopped by calling actor.stop.
Compared to the standard Scala actors, the API for processing messages is more limited: there is exactly one method that you must override. This is the receive method, which must return a PartialFunction. The receive method uses a pattern match to distinguish between various messages it can process. A pattern match is compiled down to a PartialFunction, which is the return value of the pattern match.
To send messages to actors, we’ve defined a Message trait, which various case classes that represent the actual messages extend. In principle, you can send any message to an Actor, however, in practice however, the only messages you should send should be immutable. In Scala, case classes and case objects are immutable by default, and thus are a natural fit for this. In this case, we’ve defined a ‘DoWork’ message (all messages extends from the same Message trait), which should set the Worker actor to do something that hopefully will be be of some use. When the worker receives a Die message, it will throw an exception. This is a somewhat silly example of course, but hopefully it demonstrates the idea.

So far, nothing special, apart perhaps the pre- and postRestart methods, and the field lifeCycleConfig = Some(LifeCycle(Permanent, 100)). This is configuration for Akka’s actors supervisor hierarchy capabilities. To see further how this works, let’s code up a supervisor:

import se.scalablesolutions.akka.actor.OneForOneStrategy

object WorkerSupervisor extends Actor {
trapExit = true
faultHandler = Some(OneForOneStrategy(3, 100))

def receive: PartialFunction[Any, Unit] = {
case DoSupervise(worker:Worker) =>
log.info("Supervising worker: " + worker)
startLink(worker)

case unknown =>
log.error("Unknown event: %s", unknown)
}
}

Our supervisor is also an Akka actor (in this case, it is an object, i.e. a singleton in Scala), that processes ‘DoSupervise(worker)’ messages. It handles this message by starting to supervise the worker by the invoking the ‘startLink(worker)’ method, which is defined in the Actor class. This will add our worker to the list of its linked actors, and also handles starts the linked Actor at the same time. Of cours the nice thing is that the Actor class will handle thread safety for us, so we don’t need to worry about any multithreading issues here.
The linking achieves exactly what it promises: if a linked Actor (the worker in our case) throws an exception, the supervising actor (our WorkerSupervisor) will be notified of this. For this, it is necessary to override the variable trapExit, and set it to true. It may then decide what to do based on the fault handler strategy Strategy that is defined by defining the faultHandler variable. There are currently two strategies: OneForOne, meaning that only the actor that has crashed will be restarted, and AllForOne, meaning all linked actors (including the crashed one) will be restarted. This is also where the lifeCycleConfig defined on our worker Actor comes in. LifeCycle(Permanent, 100) means our actor has a permanent LifeCycle and will always be restarted in case of an exception. The preRestart and postRestart are callback methods that may be overridden by the supervised actor to do some initialization work when it is restarted. Note that our supervised actors will probably be some kind of application services, instead of our useless Worker actor, and therefore may really need to do some usefull initialization work like setting up resources, connections, etc, in order to operate properly.

Instead of manually coding a Supervisor like we’ve done, there’s an alternative in setting up a set of linked services in a more declarative way by extending Akka’s SupervisorFactory class, as follows:

import se.scalablesolutions.akka.actor.SupervisorFactory
import se.scalablesolutions.akka.config.ScalaConfig.{LifeCycle, SupervisorConfig, RestartStrategy, Supervise, OneForOne, Permanent}

class MySupervisorFactory extends SupervisorFactory {

val worker = new Worker("worker-1")

override protected def getSupervisorConfig: SupervisorConfig = {
SupervisorConfig(
RestartStrategy(OneForOne, 3, 10),
Supervise(
worker,
LifeCycle(Permanent, 1000)) :: Nil)
}
}

object factory extends MySupervisorFactory

This defines a list of supervised actors (in our case, a one element list containing our worker) and then use the following code:

val supervisor = factory.newSupervisor
supervisor.startSupervisor

which will link all workers to one supervisor (defined within the framework) and (re)start them based on the configured strategy. You can therefore pick your preferred way of configuring.

All that remains is to see whether it actually works. For this we need a small simulation class, defined as follows:

class Simulation {

var worker:Worker = _

@Before
def setUp = {

worker = new Worker("worker-1")
WorkerSupervisor ! DoSupervise(worker)
}

@After
def tearDown = {
WorkerSupervisor.stop
}

@Test
def testSuperviseWorker = {
Thread.sleep(500)
println("\n===> start working")

worker ! DoWork("Some work")
Thread.sleep(500)

worker ! Die
Thread.sleep(1000)

worker ! DoWork("Some more work")

println("\n===> finished")

}
}

Running this shows output like the following:

INF [20091020-19:28:25.242] akka: Supervising worker: [worker-1]
DEB [20091020-19:28:25.242] akka: Linking actor [[worker-1]] to actor
[Actor[1256143591312:class akka.supervision.WorkerSupervisor$]]

===> start working
DEB [20091020-19:28:25.750] akka: start working... at: Some work
DEB [20091020-19:28:26.249] akka: Dying...
java.lang.RuntimeException: I'm dead: [worker-1]
	at akka.supervision.Worker$$anonfun$receive$1.apply(Worker.scala:48)
	at akka.supervision.Worker$$anonfun$receive$1.apply(Worker.scala:38)
	at scala.PartialFunction$$anon$1.apply(PartialFunction.scala:38)
	at se.scalablesolutions.akka.actor.Actor$class.transactionalDispatch(Actor.scala:496)
	at se.scalablesolutions.akka.actor.Actor$class.invoke(Actor.scala:461)
	at akka.supervision.Worker.invoke(Worker.scala:33)
	at se.scalablesolutions.akka.actor.ActorMessageInvoker.invoke(Actor.scala:39)
	at se.scalablesolutions.akka.reactor.EventBasedThreadPoolDispatcher$$anon$1$$anon$2.
            run(EventBasedThreadPoolDispatcher.scala:99)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
DEB [20091020-19:28:26.260] labs: pre-restarting [worker-1]
INF [20091020-19:28:26.262] labs: Restarting actor [class akka.supervision.Worker]
                                                         configured as PERMANENT.
DEB [20091020-19:28:26.265] labs: post-restarting [worker-1]

===> finished
DEB [20091020-19:28:27.251] labs: start working... at: Some more work

Process finished with exit code 0

Which indeed shows that our rudimentary supervisors work.
This concludes the introduction into Akka’s supervising actors. There is much more that Akka’s actors are capable of than shown here (remoting, transactions, STM, cassandra and mongo backend, to name just a few), but those are materials for future blogs. It may be perhaps a bit much to take all at once, as it requires to learn an API that is likely to be unknown to most of us. I won’t deny that the Akka framework certainly has some learning curve, but the reward is great once you get the hang of it.
Akka is relatively young and still evolving. If you’re interested in its future directions, check out the roadmap for the 0.6 release.

First, let’s re-iterate the rules of bowling:

1. The game consists of 10 frames. In each frame the player has two opportunities to knock down 10 pins. The score for the frame is the total number of pins knocked down, plus bonuses for strikes and spares.
2. A spare is when the player knocks down all 10 pins in two tries. The bonus for that frame is the number of pins knocked down by the next roll.
3. A strike is when the player knocks down all 10 pins on his first try. The bonus for that frame is the value of the next two balls rolled.
4. In the tenth frame a player who rolls a spare or strike is allowed to roll the extra balls to complete the frame. However no more than three balls can be rolled in tenth frame.

So in some way we need to keep track of frame scores for a game. For simplicity, I’m just using a sequence of integers that represents a game. Each integer just represents the number of pins knocked down by each throw.
This sequence should be divided, or transformed if you like, into a sequence of frames. I started with something like this:

case class Frame(first:Int, second:Int, third:Int) {
    override def toString() = {"firstThrow: " + first + " secondThrow" + second + " thirdThrow: " + third}
}

def frames(g:List[Int]):List[Frame] = {
    g match {
      case Nil => Nil
      case x::Nil => List(new Frame(x, 0, 0))
      case x::xs::Nil => List(new Frame(x, xs, 0))
      case 10 :: x::xs => new Frame(10, x, xs.head) :: frames(xs.tail)
      case x::xs::xss if ((x + xs) == 10) => new Frame(x, xs, xss.head) :: frames(xss.tail)
      case x::xs => new Frame(x, xs.head, 0) :: frames(xs.tail)
   }
}

But this might be an excellent candidate for the thedailywtf. This surely cannot be the way how to write proper Scala, and apart from that, it’s not very generic and extensible. So, after thinking about the matter a bit, a second attempt. First of all, why a class when we have functions? A sequence of frames can just be expressed as a list of lists, like so:

def frames(g:List[Int]):List[List[Int]] = {
    if (g.isEmpty) Nil
    else {
    val throws = throws_for_frame(g)
    g.take(throws)::frames(g.drop(throws))
    }
}

def frames(g:List[Int]):List[List[Int]] = {
     if (g.isEmpty) Nil
     else
        g.take(throws_for_frame_score(g))::frames(g.drop(throws_in_frame(g)))
}

def throws_for_frame_score(rolls:List[Int]):Int = {
     if (strike(rolls) || spare(rolls)) 3
     else 2
}

def throws_in_frame(rolls:List[Int]):Int = {
     if (strike(rolls)) 1
     else 2
}

def strike(rolls:List[Int]):Boolean = {
     rolls.headOption.getOrElse(false) == 10
}

def spare(rolls:List[Int]):Boolean = {
     rolls.take(2).foldLeft(0)(_+_) ==10
}

Not too bad, if you look at it from a distance some little helper functions like strike and spare even seem to be related to some of the bowling rules defined above. A frame is now just a list consisting of either 2 or 3 elements, depending on whether a strike or spare has been scored. Each element is an integer containing the pins that are knocked down.

Scoring a game now becomes a rather trivial affair, we just take the 10 frames that are bowled and add up the pins scored in each frame.

def score_game(g:List[Int]):Int = {
     framescores(g).foldLeft(0)(_+_)
}

def framescores(game:List[Int]):List[Int] = {
     frames_for(game).take(10).map(l => l.foldLeft(0)(_+_))
}

def framesThrown(g:List[Int]) = {
     frames(g).length
}

In the REPL, you can easily test these functions:

scala> framesThrown(List(4,5))
res1: Int = 1

scala> framesThrown(List(4,5,10,3,4,6,7,2))
res2: Int = 4

scala> framescores(List(4,5))
res3: List[Int] = List(9)

scala> framescores(List(4,5,6,3))
res4: List[Int] = List(9, 9)

scala> framescores(List(5,5,6,3))
res5: List[Int] = List(16, 9)

scala> framescores(List(5,5,6,3,10,10,3))
res6: List[Int] = List(16, 9, 23, 13, 3)

scala> framescores(List(10,10,10,10))
res4: List[Int] = List(30, 30, 20, 10)

And to satisfy Uncle Bob, some unit tests:

class BowlingTest {

    def repeat[T](n: Int)(what: => T): List[T] = {
        if (n==0)List.empty
        else what::repeat(n-1)(what)
    }

    @Test
    def scoreForTwoThrows = {
        assertEquals(9, score(List(4,5)))
    }

    @Test
    def strikeShouldGiveTwoExtraThrowsForScore = {
        assertEquals(List(30,30,20,10), framescores(repeat(4)(10)))
        assertEquals(24, score(List(5, 3, 4, 5, 3,4)))
        assertEquals(32, score(List(10, 3, 4, 5, 3)))
    }

    @Test
    def spareShouldGiveOneExtraThrowsForScore = {
        assertEquals(24, score(List(5, 3, 4, 5, 3, 4)))
        assertEquals(30, score(List(5, 5, 4, 5, 3, 4)))
     }

    @Test
    def spareAtEndShouldGiveOneExtraThrowsForScore = {
        assertEquals(60, score(List(4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 6, 5)))
        assertEquals(54, score(List(4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 5, 5)))
     }

    @Test
    def strikeAtEndShouldGiveTwoExtraThrowsForScore = {
        assertEquals(65, score(List(4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 10, 5, 5)))
        assertEquals(54, score(List(4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 5, 5)))
     }

    @Test
    def tears = {
        assertEquals(299, score(List(10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9)))
     }

    @Test
    def perfectGameShouldScore300 = {
        assertEquals(300, score(repeat(12)(10)))
    }

    @Test
    def allOnesShouldScore20 = {
        assertEquals(20, score(repeat(20)(1)))
    }
}

It’s still a bit simplistic (for example, framesThrown doesn’t really check whether a frame is finished, i.e. whether two or three throws have been made, there’s no validation that the number of pins knocked down cannot be larger than 10, games can have an infinite length, etc, etc). However I’ll leave it at this for the moment, and will try to perfect it later. It has already been a nice exercise so far in any case. As stated, my Scala knowledge is such that this implementation can most likely be heavily improved upon. If you have suggestions for improvements (or have an implementation of your own) your comments are highly appreciated.

Update
As Ilian Berci has pointed out, my satisfaction at my original attempt was completely misguided. Somehow I managed to misinterpret the bowling rules completely. I managed to get into my mind that a strike would give two extra throws, in each frame. However, if you have once taken up a game of bowling yourself you know that this is complete nonsense. It is only so that the next two throws (which are then part of another frame) contribute to the frame in which the strike is scored. It is only at the tenth frame that the bowler gets an extra frame (consisting of maximum two throws) if he scores a strike at his final games. So, my original framescores function and helper function looked like below:

def frames(g:List[Int]):List[List[Int]] = {
    if (g.isEmpty) Nil
    else {
    val throws = throws_for_frame(g)
    g.take(throws)::frames(g.drop(throws))
    }
}

def throws_for_frame(rolls:List[Int]):Int = {
    if (strike(rolls) || spare(rolls)) 3
    else 2
}

which is utterly wrong, since it places all the throws that contribute to a frame score in the same frame (and removes them from the remaining games list). This makes that a game in my original version could take up to 30 throws, instead of the 21 maximum throws possible.
So, in my original version, the framescores functions behaved like this:

scala> framescores(List(5,5,6,3))
res14: List[Int] = List(16, 3)

scala> framescores(List(10,10,10,10,10))
res15: List[Int] = List(30,20)

Fixing it didn’t take much time however, which was a relief because I thought I had completely messed up. I’ve updated the post with a version which is (hopefully) now correct (so you can see the fix in the frame function and helper functions throws_for_frame_score and throws_in_frame), and also updated the tests into some more sensible ones. The wtf version is still left to its original, fixing that would probably even make it more horrible than its original. Thanks to Ilian for pointing this out, clearly can’t beat Uncle Bob.

Get the trunk
To use the trunk, you can either check out the sources and build it yourself, our take the nightly builds. You’ve probably set a SCALA_HOME environment variable, so just point it to the newly created build and fire up the REPL. If all has gone well, you should see something like the following:

Welcome to Scala version 2.8.0.r18341-b20090718103640 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_14).
Type in expressions to have them evaluated.
Type :help for more information.
scala>

Using the trunk, the first thing you can profit from is using the redesigned and improved Scala collection library.
It has undergone a large redesign effort, largely done by Martin Odersky himself. It has been checked in and been living in the trunk for a while now, so using the trunk you can have the advantage working with it. The new API is explained in the Scala Improvement Proposal, an excellent and must read for understanding the design of Scala’s collections.

Using the revamped REPL
Paul Phillips not only solves one bug after the other in the trunk, he also has the habit of pimping the REPL on a regular basis.
A very nice feature is that there is code completion, very handy if you don’t have the complete Scala API in your head. First, define a variable and after typing the variable (and possibly the start of a function) hit tab:

scala> val l = List(1,2,3)
l: List[Int] = List(1, 2, 3)
scala> l
AbstractStringBuilder       Annotation                  Appendable                  Application
Array                       AssertionStatusDirectives   BigDecimal                  BigInt
Boolean                     Byte                        Cell                        CharSequence
Character                   CharacterData00             CharacterData01             CharacterData02
CharacterData0E             CharacterDataLatin1         CharacterDataPrivateUse     CharacterDataUndefined
Class                       ClassLoader                 ClassfileAnnotation         Cloneable
Comparable                  Compiler                    ConditionalSpecialCasing    Console
CountedIterator             Deprecated                  Double                      Either
Enum                        Enumeration                 Equiv                       Float
Fractional                  Function                    GenericRange                Immutable
InheritableThreadLocal      Integer                     Integral                    Iterable
Left                        Long                        Math                        Mutable
None                        NotNull                     Number                      Numeric
Object                      Option                      Ordered                     Ordering
Override                    Package                     PartialFunction             PartialOrdering
PartiallyOrdered            Predef                      Process                     ProcessBuilder
ProcessEnvironment          ProcessImpl                 Product                     Proxy
Range                       RangeToString               Readable                    Responder
Right                       Runnable                    Runtime                     RuntimePermission
ScalaObject                 SecurityManager             SerialVersionUID            Short
Shutdown                    Some                        StackTraceElement           StaticAnnotation
StrictMath                  String                      StringBuffer                StringBuilder
StringCoding                SuppressWarnings            Symbol                      System
SystemClassLoaderAction     Terminator                  Thread                      ThreadDeath
ThreadGroup                 ThreadLocal                 Throwable                   TypeConstraint
UNIXProcess                 Unhashable                  UniquenessCache             Void
actors                      annotation                  ch                          cloneable
collection                  com                         compat                      concurrent
dbc                         deprecated                  inline                      instrument
io                          java                        javax                       jline
l                           management                  mobile                      native
net                         noinline                    org                         package
ref                         reflect                     remote                      runtime
scala                       serializable                settings                    specialized
sun                         sunw                        swing                       testing
text                        throws                      tools                       transient
unchecked                   unsealed                    util                        volatile
xml

scala> l.zip

zip            zipAll         zipWithIndex

Pretty neat. But that’s not all: the trunk REPL now contains a power user mode:

scala> :help
All commands can be abbreviated - for example :h or :he instead of :help.

:help prints this help message.
:jar add a jar to the classpath.
:load followed by a filename loads a Scala file.
:power enable power user mode.
:quit exits the interpreter.
:replay resets execution and replays all previous commands.
:silent disable/enable automatic printing of results.

scala> :power
** Power User mode enabled - BEEP BOOP      **
** New vals! Try interpreter.          **
** New defs! Try mkType("T", "String")      **
** New cmds! :help to discover them         **

:help prints this help message.
:jar add a jar to the classpath.
:load followed by a filename loads a Scala file.
:power enable power user mode.
:quit exits the interpreter.
:replay resets execution and replays all previous commands.
:silent disable/enable automatic printing of results.
:dump displays a view of the interpreter's internal state.
:tree displays ASTs for specified identifiers.

Let’s try some of this. Using mkType we can define a type alias, just as Haskell:

scala> mkType("IntList", "List[Int]")
defined type alias IntList
res3: scala.tools.nsc.InterpreterResults.Result = Success

scala> val il: IntList = List("1","2","3")
:5: error: type mismatch;
 found   : java.lang.String("1")
 required: Int
       val il: IntList = List("1","2","3")

scala> val il:IntList = List(1,2,3,4)
il: IntList = List(1, 2, 3, 4)

scala> il.foldLeft(0)(_+_)
res5: Int = 10

Works like a charm.

Next, the :tree command displays some AST for classes and functions you’ve defined, if you’re interested in this:

scala> def sum(a: Int)(b: Int)(c: Int) = a + b + c
sum: (a: Int)(b: Int)(c: Int)Int

scala> :tree sum
def sum(a: Int)(b: Int)(c: Int) = a.$plus(b).$plus(c) (DefDef)

Last but not least, we can make use of Scala’s new cutting edge features. For instance, Scala has limited support for applying tail call optimizations at compile time. Determining whether the compiler actually will perform this optimization can be a tricky business however. If you’re using this, but are unsure whether a function that you have written will actually be optimized by the compiler, you can use the @tailrec annotation now. For instance (the example is taken from the Programming in Scala book) the boom function shown below is not tail recursive, because of the increment function at the end. The bang function on the other hand is.

import scala.annotation.tailrec
class Tails {
  @tailrec def boom(x: Int): Int = {
  if (x == 0) throw new Exception("boom!")
  else boom(x-1)+ 1
}

  @tailrec def bang(x: Int): Int = {
  if (x == 0) throw new Exception("bang!")
  else bang(x-1)
  }
}

Using the @tailrec annotation on both, the compiler gives the following error:

:8: error: could not optimize @tailrec annotated method
         @tailrec def boom(x: Int): Int = {
                      ^
:13: error: could not optimize @tailrec annotated method
         @tailrec def bang(x: Int): Int = {

A bit confusing at first sight, since we get compilation errors for both methods, while we were pretty sure the bang method should be tail recursive. However, this can be explained by the fact that the bang method is defined in a class as public and not final. This means it could be overridden in a subclass, thereby preventing tail call optimization. Subtleties like this really makes this annotation quite useful. If we change the class into an object (for which methods can’t be overridden), and remove the @tailrec annotation from the boom method, all compiles fine.

For more tail call and trampolining explorations in Scala, Rich Dougherty’s blog is a good place to start. Also check out the Scala’s TailRec class, which is available in the trunk, and this thread for discussion of it.

I haven’t touched all of the new features that will be in Scala 2.8.0, but some a basic overview can be found here. Take a look and enjoy.

To start: here’s the original implementation in Java:

// From Apache Commons Lang, http://commons.apache.org/lang/
public static int indexOfAny(String str, char[] searchChars) {
  if (isEmpty(str) || ArrayUtils.isEmpty(searchChars)) {
      return -1;
  }
  for (int i = 0; i < str.length(); i++) {
      char ch = str.charAt(i);
      for (int j = 0; j < searchChars.length; j++) {
        if (searchChars[j] == ch) {
            return i;
        }
      }
  }
  return -1;
}

Sample results of this function are:

StringUtils.indexOfAny(null, *)                  = -1
StringUtils.indexOfAny("" , *)                    = -1
StringUtils.indexOfAny(*, null)                  = -1
StringUtils.indexOfAny(*, [])                    = -1
StringUtils.indexOfAny("zzabyycdxx" ,['z' ,'a' ]) = 0
StringUtils.indexOfAny("zzabyycdxx" ,['b' ,'y' ]) = 3
StringUtils.indexOfAny("aba" , ['z' ])            = -1

And now the Clojure code. I’ve taken the version from the book, (free to download here). The book version defines three functions, instead of the version shown in the blog post.

(defn indexed [s] (map vector (iterate inc 0) s))

(defn index-filter [pred coll]
  (when pred
    (for [[idx elt] (indexed coll) :when (pred elt)] idx)))

(defn index-of-any [pred coll]
  (first (index-filter pred coll)))

The three functions defined are:

1. indexed returns a sequence of pairs, the first element being the index, the sequence the element.
2. index-filter returns a sequence of the indexes of matching predicates in the collection. For example, the function call (index-filter #{\a \b} “abcdbbb”) yields (0 1 4 5 6)
3. index-of-any is the StringUtils function. This is now a simple function, just returning the first result of the index-filter function.

As Stuart has mentioned in his book, the Clojure version is shorter, less complex, and also more general than the Java version. No special case handling, such as null or empty search character checking. This all just works naturally in the functional version. It can also be easily extended for other functions than just indexOfAny
Since I’ve been implementing all kinds of nice, but useless little functions in Scala recently, I thought it might be a good idea to try out a more useful example. So let’s see how well we can do with Scala in implementing this in a similar way as the Clojure version.
Almost immediately, we hit on the dreaded null problem. Scala is not a pure functional language, and you have to beware that parameters that are passed on can be null. You could specify the input arguments as Options, of course, but than the caller of the function still needs to construct either the Some or None value, and to do that the caller would have to check for it being null or not.
So, after spending some time grumbling about this issue, I decided to admit defeat and do the null check. 1-0 for Clojure.

Without further ado, here are the three functions implemented in Scala (N.B. I’ve used the trunk here, in case you might want to try this out yourself, I haven’t tried whether this also works version 2.7.5):

def indexed(coll:Seq[Any]):Seq[Pair[Int,Any]] = {
  if (coll==null) List()
  (0 until coll.length).zip(coll)
  //below an alternative, but here we have to traverse the list another time to reverse the elements...
  //coll.zipWithIndex.map(p => p.swap)
}

def indexedFilter(pred:Seq[Any], coll:Seq[Any]):Seq[Int] = {
  if (pred==null)List()
  val idxList = indexed(coll)
  for (p <- pred; idxPair <- idxList; if (p == idxPair._2)) yield (idxPair._1)
}

def indexOfAny(pred:Seq[Any], coll:Seq[Any]):Option[Int] = {
  val res=indexedFilter(pred, coll)
  if (res.isEmpty) None
  else Some(res.first)
}

Following the definition of the indexed function is a no-brainer: Scala’s zip function on the List class does the job here. There’s also zipWithIndex which does almost what we want, this returns a List of tuples, but in reverse order as the Clojure sample: element first, index later.
The indexedFilter uses a for-comprehension just as the Clojure example (Clojure’s for is not a traditional loop, but a sequence comprehension). For each element in our predicate sequence it checks whether it is present in the indexed tuples that is the result of the indexed function. If it is, it is added to the resulting list using yield. indexOfAny then becomes a trivial function that just checks whether the resulting sequence is empty or not. Instead of returning -1 if nothing is found, I’ve used Scala’s Option class in this case to make the result more expressive.

The function at least works as expected:


scala> indexOfAny("ab", "cdef")
res3: Option[Int] = None
scala> indexOfAny("ab", "bcdefbbb")
res3: Option[Int] = None
scala> indexOfAny("fb", "bcdefbbb")
res4: Option[Int] = Some(4)


Conclusion
All in all, the scala version is not that bad. Its main drawback over the Clojure version is the two null checks that we need to do, and also we need to check the resulting list being empty or not in the indexOfAny function. Clojure wins in this respect. However, the Scala version still is pretty neat and generic and improves (in my opinion at least) the original Java version.

Update: handling infinite collections
Stuart asked the question in his comment how the Scala version would handle infinite collections. The version presented above does not handle this very well. For instance, you’ll get a OEM if you try to pass on Stream.from(0) (which constructs a lazy infinite list of all natural numbers) to the indexed function. Also the indexedFilter function evaluates the entire collection, which is strictly not necessary for the indexOfAny function. To handle an infinite collection, we need to modify and optimize the functions somewhat, to resemble a bit more the functions that Stuart has used in his blog post, instead of the book versions. The Clojure functions used in the blog post look like this:

(defn indexed [s] (map vector (iterate inc 0) s))

(defn index-of-any [s chars]
  (some (fn [[idx char]] (if (get chars char) idx))
          (indexed s)))

The Scala version that I came up with is as follows:

def lazyIndexed(coll:Seq[Any]):Seq[Pair[Int,Any]] = {
  if (coll==null) Stream.empty
  Stream.from(0).zip(coll)
}

def lazyIndexOfAny(pred:Seq[Any], coll:Seq[Any]):Option[Int] = {
  if (pred==null) None
  lazyIndexed(coll).dropWhile(ip => !pred.exists(p => (p == ip._2))).headOption.map(ip => ip._1)
}

As said, Scala’s Stream implements a lazy list, in which the elements are only evaluated when needed. In this case, we keep on drop elements from it list that do not appear in the predicate sequence. The head of the remaining list is the first matching result.

Obvious drawback here is that this indeed does works on infinite collections, but only if a match can be found, else we’re still in trouble.

Pick an IDE, or not
The first problem you might encounter is that the various Scala IDE plugins have not yet reached the maturity of the Java support that you might have been accustomed to. Lots of hard work is in progress on this, but you still might experience hickups and freezes (as I have) of your favorite IDE. At this moment, the Netbeans plugin seems to be the most stable (this is the IDE that David Pollak, creator of Lift, seems to use). If you’re an eclipse user, you’ll probably want the nightly build version of the Scala plugin, since that’s the only one actively under development. This means that you need the Scala trunk to work with, however.

There’s also plenty of support for non-IDE’s, and recently I’ve tried switching back to emacs again. For some, this brings back memories to good old university days, others may find it the utmost horror. I must say, I found it to be a rather soothing experience after years of development using Eclipse. You’ll need to do some setup work to get a good Scala experience. An excellent blog post describing how to setup your emacs environment for Scala using Yasnippet, exuberant ctags and maven can be found here.

Try out the trunk
The latest released version of Scala is 2.7.5. The next version will be 2.8.0, but its release date is still not known. However, the invaluable Paul Philips has done many bug fixes and improvements in the Scala compiler and the REPL, all hanging out in the trunk. To take full advantage of this, check out the sources and build them. Note that the Scala collections API has been redesigned in the trunk, and differs from the 2.7.5 release. To get a good understanding of the new design, and the API in general, you’re encouraged to read the new collection SIP (Scala improvement proposal) available here.

Read a book
The standard work is Programming in Scala, co-authored by Martin Odersky (creator of Scala) himself. This book is lengthy but very thorough, providing plenty of examples. Another book that has seen the light is Beginning Scala by David Pollak (already mentioned). I have not read this, but reviews suggest this is also an excellent start. More books will hit the market this year.

Check out Lift
Eventually it is possible that you might start to really like Scala and want to use it in the enterprise. Lift is the first web framework written in Scala, created by David Pollak. Downloading and creating a simple web application to work is a no-brainer. The distribution comes with plenty of maven archetypes to get a basic web application ready in under than five minutes. Lift has its own database mapping framework, but there’s JPA support as well, if you like this. JTA integration is also being worked on.

Read some articles
There are loads of (both academic and slightly less academic) articles about Scala. For example, if you want to know the rationale behind Scala’s actor library design, read the scala actor papers.
Martin Odersky’s homepage also contains a long list of his publications.
It provides lots of material to provide insight in the design of Scala and its libraries. If you’re not that academically inclined and from a Java background, try The busy java developer’s guide to Scala, by Ted Neward. Provides a nice introduction.

Read some blogs.
Plenty of blogs available, here are some I like:

• Daniel Spiewak Lots of useful Scala examples.
• Tony morris. He’s the creator of functional java and of Scalaz. Beware however, if you check this out you might end up in deep functional waters where Monads reign.
• Jonas BonerHe has lots of experience of using Scala in the real world, some of which he has blogged extensively about. Well worth the read.
• Planet Scala Perhaps you don’t even need more than this. This aggregates numerous blog posts (including the one mentioned above) about Scala.

Join IRC
Scala has an IRC channel, which can be found here. Whenever you’re stuck at some problem you’re working at, there’s always the mailing lists, but many knowledgeable people hang out on a daily basis on the IRC channel. Use lodgeit to show the code you’re stuck with, and you’ll get an answer in no time.

Start coding.
Lift might be the choice if you really want to write some useful, practical real world web applications. If you’re totally impractical like me, pick a few problems from project euler, or the 99 problems projects (solutions in Scala can be found here. Many excellent programmers have taken this path, it’s fun and an excellent way to play around with the core Scala API.

To put into practice what I preach here, a few lines of Scala code to either whet your appetite or make you run away screaming. Note that my Scala knowledge is still in the pre-kindergarten stage, I’m barely able to speak, so laugh at will when viewing this code.

First, a randomly picked Euler problem, number 48, just because I like onliners:

(1 to 1000).map(x => new java.math.BigDecimal(x).pow(x)).reduceLeft((a,b) => a.add(b)).remainder(new java.math.BigDecimal(10).pow(10))

This one liner is not nearly as concise and neat as the Haskell version, but it will do. If nothing else, it has at least has the tiny merit of showing Scala – Java interoperability.

Another randomly picked and slightly more complex one, problem number 21:

object Euler21 {
  def sumOfDivisors(number: Int): Int = {
    List.range(1, number).filter{i => (number % i) == 0}.foldLeft(0){(a,b) => a+b}
  }

  def solver(): Int  = {
      (for (i <- 0 until 10000; di = sumOfDivisors(i); if(di > i && sumOfDivisors(di)  == i) ) yield (i+di)).foldLeft(0){(a,b) => a+b};
  }
}

Enjoy.

To start with an example, the generic DAO interface looks like this:

public interface GenericEntityDao {

   T findById(Serializable id);

   List findAll();

   ... more methods omitted
}

And its generic DAO implementation class looks something like this:

public abstract class GenericJpaDao implements GenericDao {

  private Class entityBeanType;

  @PersistenceContext
  private EntityManager entityManager;

  public T findById(Serializable id) {
     return entityManager.find(getEntityBeanType(), id);
  }

  public List findAll() {
      return entityManager.createQuery("from " + getEntityBeanType().getName() )
                          .getResultList();
  }

  protected Class getEntityBeanType() {
      return entityBeanType;
  }
  ... more methods omitted

}

The question is, how do we obtain the parametized type of T for the entityBeanType field to use in our queries? Earlier, I used to just instantiate this type in the constructor, like so:

public GenericJpaDao(Class entityBeanType) {
     this.entityBeanType = entityBeanType;
}

public JpaPersonDao extends GenericJpaEntityDao implements PersonDao {
   public PersonDao() {
      super(Person.class);
   }
}

But this is a bit silly, since we already know from the type parameter that the entity we’re interested in has type Person.
However, there is an easier way out: we can use Java’s ParameterizedType class to obtain information about the declared generic type. As stated in the javadoc:

/**
* ParameterizedType represents a parameterized type such as
* Collection<String>.
*
* A parameterized type is created the first time it is needed by a
* reflective method, as specified in this package. When a
* parameterized type p is created, the generic type declaration that
* p instantiates is resolved, and all type arguments of p are created
* recursively.

Thus, it seems that ParameterizedType contains the information that we want. How do we obtain an instance of it? The answer lies in Java’s getGenericSuperclass method, defined on the Class object. This returns a Type representing the superclass of this Class. The Javadoc of the method states the following:

* If the superclass is a parameterized type, the Type
* object returned must accurately reflect the actual type
* parameters used in the source code. The parameterized type
* representing the superclass is created if it had not been
* created before.

The Type interface itself is just a marker interface, containing no methods. Depending on the case at hand, an Type extending the Type interface will be returned. In our case, we’ll use the getGenericSuperclass method on a class extending our GenericJpaDao class. Thus, the superclass is JpaGenericDao, which is a parameterized type. In this case, the actual the Type object returned by getGenericSuperClass will be a ParameterizedType instance. This class contains a method getActualTypeArguments, which returns an array containing all generic type parameters used in the source code.

This is precisely what we desire, so in our GenericJpaDao class constructor, can get rid of the Class argument, and instead do the following:

  @SuppressWarnings("unchecked")
  public GenericJpaDao() {
    this.entityBeanType = ((Class) ((ParameterizedType) getClass()
        .getGenericSuperclass()).getActualTypeArguments()[0]);
  }

We know there’s precisely one type argument in our class, so we can take the first element of the array that is returned, which provides the Class of our entity. Thus we can get rid of all the annoying constructors with Class arguments, and handle determination of the entity type in just one place.

This may not provide the highest amount of code reduction you have ever experienced, but it’s a neat trick in any case.

The track started of with what seemed like a rather unusual combination: a presentation by Paul Hudak about Haskell and the Arts.
He talked about the concept of Functional Reactive Programming (FRP), now a key area of research at the University of Yale. FRP is a programming style where each function can capture a time varying quantity (for instance input sound, video, user actions). This style of programming has applications in Robotics, parallel programming, audio processing. Whenever a new input value is given to a function, it is re-evaluated and new output is returned. In his talk, he presented specially HasCore and HasSound, domain specific languages developed for music and sound synthesis. Paul said that functional languages are specially suited for computer music, as they are declarative (saying ‘What’ should be done, instead of ‘How’ it should be done). Haskells abstraction mechanisms allow for musical programs that are elegant, precise and powerful, using the mechanisms of lazy evaluation, higher order functions, algebraic data types and type classes. A basic example of music modeling in Haskell can be found here.

The next talk was given by Lennart Augustsson on a very different subject, yet no less interesting: implementing Domain Specific Languages in Haskell. It seams that, whenever the topic of DSL’s is mentioned to a Haskell programmer, a wry smile will appear on his face, since this has been done since ages in Haskell already, and it’s hard for him to see why it’s currently such a hype.
Lennart gave a couple of examples which he himself had developed by implementing DSL’s in Haskell. For me, the most striking was the case where he had implemented a DSL for generating Excel (i.e. the real Excel sheets, not just a text based csv file). As he stated, Excel has a somewhat rudimentary abstraction mechanism, consisting only of copy and past re-use. However it is used widely by business people and is a familiar UI. Therefore, the solution is to generate Excel sheets. Lennart is an advocate of strong type checking to prevent errors at compile time. He showed how he had used Haskells type classes, and also a more obscure concept as Phantom types in his Excel DSL. The result was a DSL capable of generating Excel sheets without allowing type errors in operations, such as the addition of two cells in Excel where one contains an integer and the other containing a string, a thing that Excel itself does not prevent. An interesting and also amusing session indeed, showing the full power of Haskells type system capabilities, and demonstrating a use of it in an area that probably does not spring directly to the mind when thinking of Haskell.

A perhaps more familiar concept to most of us was demonstrated in a session given by David Pollak . He talked about a web application, Buy a feature, that he had developed recently. A subject that perhaps will not raise most interest immediately, however, David had used Scala and Scala’s Lift web framework, the latter being created by himself. He had been using functional programming paradigms, including Scala’s Actor library to deal with concurrency, in order to implement a multi-user, web-based, real-time, serious game. As he stated, the team initially used the Java’s imperative programming style. However, after some time (and coaching) they gradually move over to use the declarative, functional programming style that Scala also offers. Some more noteworthy statements were, that none of the bugs found in the application were concurrency related, apparently the event driven, message passing programming style using Scala’s Actor library served him well.
Also, he stated, the amount of unit tests he needed to comfortably put this system into production had been considerably less (in the order of 30% if my remember correctly) compared to the amount of test coverage required when using Ruby and Rails, which he has also been using extensively. An interesting case study, and one of the first real world examples about Scala’s usage that I had heard of. If you’re interested, read David’s blog) for more on this topic.

The day’s ending could not have been much better for a functional programming adherent.
Eric Meijer himself concluded it, with a delightful talk titled ‘The fundamentalist functionalist programming’. His thought provoking argument is that we’ve been moving into the wrong directions for the last dozens of years in the way we program, and it’s time to see change direction. Turning, as the title of this blog indicates, to pure, fundamental functional programming.
Why would this be a good thing? All ‘pure’ functional code has no side effects, and therefore does not alter state. Lacking state that is altered, the order in which statements are executed does not matter, nor does number of times a program gets executed. This makes programs better understandable and far less error prone. How nasty an implicit side effect of a function can be was shown by Eric with an example from the C# language. It would make this blog too lengthy to go into detail, so for the interested reader should take a look at his blog.

Now, many will think along these lines: ‘no side effects, thus, no use’, specially when thinking about how to do IO, which always causes some side effect. Actually Eric’s main argument about fundamentalist functional programming was not that all side effects are bad. Indeed he argued that any program can have side effects, and that side effects are even a good thing. However, his main argument was that all side effects should be made explicit in the language. It’s the implicit side effects hidden in function or method calls that leads to surprising and unexpected results and as a consequence lengthy debugging sessions. Even Erlang is not a ‘pure’ functional language in the fundamentalist sense, since IO operations as well as the spawning of a new process do have side effects that are implicit in the language.
The language Eric has taken part in designing, Haskell, is naturally the language he is advocating to use, and if not the language itself, then at least its ideas. In Haskell, all side effects are coded in Monadic classes. Eric gave a simple example about this concept, stating that a Monad can be simply be understood as a Collection of values of things that change. He made the comparison of a watch being a Monad, of which the time has a different value each time you take a look at it. The watch does not change itself, but the value it represents does. Monadic classed can be passed around functions without letting side effects escape the Monadic class itself. By using this mechanism, it is immediately obvious which parts of a program actually do change state, and this makes programs easier to understand.
One might think that these concepts are still only of academic interest. However, as Eric showed, it’s already out there in LINQ, .NET’s language-integrated query, set, which uses Monadic classes and lazy evaluation. So if you if you’re a C# programmer, you’re already dealing with these functional concepts. C# incorporates more and more functional features into the language.

A very thought provoking talk that made me think why the whole world is not using a functional programming style. However, after this day, I’m convinced that functional programming is very much alive, and we’ll see an increasing use of it and its ideas in our daily work. I think we need to embrace those ideas to take full advantage of them in our problem solving and, ultimately, to write better programs.