Protogrid is a dynamically typed, prototype based programming language that runs on the JVM.

It can be found on github at http://www.github.com/brweber2/protogrid

For users:

Protogrid strives to be simple to write and read.  Each form is intended to mean one thing so there should not be any confusion once you become familiar with the syntax.  In many ways this one to one mapping of syntax and semantics has been a simplifying and limiting factor in the design of the language.  This is especially true for developers who come to protogrid with pre-conceived notions from past experience.

• There is a single keyword 'var'.
• nil, undefined, true and false are built in prototypes.
• In protogrid there is a single numeric type.
• Variable names cannot contain numbers.
• Parenthesis always indicate function application, even there is no function to apply. For example, parenthesis used for changing or specifying order of operation precedence are strictly evaluated and the resulting value is left as the current context, but no function invocation actually takes place.
• Brackets indicate a function declaration.
• Braces indicate a scoped block.
• Single = denotes assignment.

Unfortunately, there isn't much here that will excite you.  Protogrid introduces virtually no new programming paradigms, it merely strives to make the developer experience more enjoyable.  The current form of Java interop is not something I've seen in any other language that runs on the JVM, but it is not something new or revolutionary.  It is arguably a nicer reflection API.  And yes, you will cringe if you look under the hood.  The implementation is insanely naive and non-performant in every aspect imaginable. Java Interop

To start interacting with the underlying Java platform, the first step is typically to wrap a Java class.

var JavaString = WrapClass( java.lang.String )

The JavaString prototype now is a wrapped Java class.  It can be used in one of two ways.

• If invoked the arguments are used to determine which constructor should be called at runtime and if successful a wrapped instance is returned.
• Accessing a slot on the wrapped class will look for a field.  If one is found a wrapped field is returned.  If no field is found, a wrapped methods prototype is returned that wraps all the static methods on the class with the matching name.  If this wrapped methods prototype is invoked it uses the arguments passed to it to determine at runtime which specific method should be invoked and a wrapped instance is returned with the result of the invocation.

var message = JavaString.format( "Hello %s", "World!" )

There are a few points of interest here.  There is more than one static format method on java.lang.String.  Additionally, the String "World!" is converted to an Object[] to support the variadic version of the format method used here. A wrapped instance is a prototype that can be used with the protogrid, but that can be coerced back to its native Java type when necessary.

println( message.toUpperCase() )

What's missing from the interop story?

Quite a bit.  There is currently no way to implement an interface, to extend a class or to create a new interface or class.

Show me more!

Creating a new prototype Simply clone an existing prototype

var MyProto = clone( Object )

Setting and accessing slots on the prototype is trivial

MyProto.foo = "barbaz"

println( MyProto.foo )

Inspecting the prototype

println( MyProto.slots() )

Viewing the AST

At any point, the built in ast function can be called to print out a readable form of the Abstract Syntax Tree if there is every any doubt about what the interpreter is seeing.

ast( 2 + 3 * 4 ^ 5 % 6 )

This will result in the following AST

(  2   +  ( (  3   *  (  4   ^   5  )  )   %   6  )  )

Loading code from a file

When loading code from a file, any side effects will occur at load time and a scope object with all the top level definitions from the file will be returned.  This can be assigned to a variable and values and functions can be accessed without worrying about collisions within the current scope. Suppose we have a file located at src/hello_world.grid relative to the current directory with the following content.

var sayHelloTo = [name] { println( strf( "Hello %s" List(name) ) ) }

To load this file, simply call the built in load function.

var ns = load( "src/hello_world.grid" )

ns.sayHelloTo( "Flynn" )

If you do not want to namespace any particular functions it is possible to map them into the curent scope by simply assigning them to a variable.

var sayHelloTo = ns.sayHelloTo

Operators

Math + - * / % ^ Logic && || Comparison == != < <= > >=

Control Flow

There are built in functions for conditionals, looping, exceptions and exception handling. Conditionals

if ( true println( "true" ) println( "false" ) )

if ( <cond><true expr> <false expr> )

Looping

loop( <structure> <function> )

The function passed to loop must have two parameters, the value for each iteration and in the index number of the iteration (zero based).

while( <condition> <block> )

Exceptions

var err = error( "Uh oh" )

raise( err )

try ( <block> <finally-block> )

But what about catching the exceptions?  A try block does not return the result of the block, it returns an object that contains a boolean indicating whether or not an exception was thrown and either the exception or the resultant value.  It is therefore possible to access slots on the resultant prototype to perform whatever error handling is necessary.

var t = try( socket.write() socket.close() )

if ( t.hasError raise( t.error ) t.result )

Composite Data Structures

There are lists. There is a built in function to construct them and they can contain an object of any type.  Lists are zero indexed for access operations.

var names = List( "Kevin", "Sam", "Quorra" )

println( names.get( 1 ) )

Because I have to...

Hello World

println( "Hello world!" )

Factorial

var fac = [n] {
    if ( n == 0 || n == 1
    1
    n * recur( n - 1 )  )
}

In protogrid, recursion is achieved by calling the recur function instead of the current function by name.

Getting started

The best way to get started is to download the executable protogrid jar and start experimenting with the REPL.  Syntax highlighting for IntelliJ IDEA and TextMate will be added to github in the very near future.

Down the road

• Syntax highlighting
• Compiled version
• Debugger
• Static typing
• Lazy evaluation
• Macros
• Named arguments
• Default values for parameters
• Richer Java interop
• De-structuring
• Targeting other platforms

Cliff Click's demo of Azul Systems tool was very, very impressive (and only about a dozen people saw it). His presentation was also good. This type of low level HotSpot support is necessary for language designers who are serious about performance and $40k seemed reasonable for a machine if you get Cliff's expertise along with it!

In addition to some C# by Mads, Allison Randal spoke about the Parrot VM. I was happy to see that Sun had the openness to invite Microsoft and Parrot to take part. I think that it really added to the quality of the summit. Google had some folks present, but didn't really talk about how they use the JVM. Next year, I would love to see some more activity from Google.

Parrot is a register based VM which makes some things (ie continuations) easier to implement, but I think that it might be quite some time before the performance can match the HotSpot JVM for most things. Parrot has been around for 7 years so they just have not had as much time (and money?) to devote to making it as mature as the JVM.

Thinking about going to the JVM language summit next year? I highly recommend the event, but it is a small group of highly experienced language designers. So the following words should not scare you: invariant, covariance, type erasure, continuations, tail call optimization, etc. You probably also should have some experience implementing your own language and/or working extensively at the byte code level. It will also help to be familiar with the symbols used to describe type systems. I don't mean to scare anyone away, but I recommend that you make an honest assessment if the event is right for you. Otherwise you might have a good time but not be able to take part in the conversations. If this is your thing, Microsoft also has a Lang.NET conference you might want to check out.

My only suggestion to Sun: use a room with a screen that is elevated a little more so the entire room can see the full screen.

Summary

• LINQ - Functional programming features in C#.
• Kawa - Scheme without full continuations.
• Fundamentalist Functional Programming - Turn your world upside down presentation. Described in detail above.
• NetRexx - An old IBM scripting language that has been open sourced.
• Scalify - Library to take Java code as input and produce Scala as output. Looking for others to join to add Java -> "other JVM language" implementations as well.
• Closures and the JVM - Mostly discussed language interoperability on the JVM and the problems languages face when trying to use libraries written in other languages (with Java being somewhat of an exception). If you haven't heard by now, Neal is also working for Microsoft.
• Bytecodes for fast JVMs - Showed low level metrics for Clojure, JRuby and Jython. Cliff was able to identify areas where teams thought that something was being inlined, but in fact was not.
• Jatha Common Lisp - What Ola Bini worked on before JRuby.
• Parrot VM - Register based VM.

Many thanks to Sun for hosting a spectacular event. In particular, thank you John Rose for taking the time on several occasions to chat. I know you were very busy.

Overall impressions: many people here are "into" functional programming languages. Concurrency is another big topic. This conference has just the right blend of academia and "real world" for me. It is very technical, but not so full of Greek letters that your head hurts.

• Gosling keynote - History of Java.
• JavaFX - How they use javac to compile JavaFX.
• JRuby - How they have blazed the trail for dynamic languages on the JVM.
• ASM - The library for byte code manipulation.
• PHP - Not totally sure why, but they are working on it. Overall, I think its good to have as many mainstream languages on the JVM as possible.
• MOP - Metaobject protocol for passing objects between dynamic languages on the JVM. Like the idea, not sure sure about the implementation.
• invokedynamic backport - I can't get enough details about invokedynamic.
• Clojure - Functional language on the JVM. The highlight of the day for me. It's not 100% what I would like to see, but it is the closest yet.
• Python gradual typing - Typing notation makes your head spin, but a very good talk.
• Jython - Sort of opposite situation from the CLR/DLR. On the DLR IronPython came before IronRuby and Ruby.NET and really blazed the trail. On the JVM Jython has been around, but they seem to be in a complete re-write and are really leveraging a lot from JRuby (and that is very, very good).

Final observation: I'm very impressed with how approachable the 80 or so odd people here are, especially the Sun employees. Granted they are the hosts, but they have really taken their time to interact with the participants (as they should because I really don't think that they would want to alienate this crowd in particular!).

Day 1 of the JVM language summit in Santa Clara has come and gone. The agenda can be found at Agenda.

The highlight of day 1 for me was John Rose talking about invokedynamic. A lot of attendees really liked the talks about Fortress and multiple dispatch, but invokedynamic was the most relevant to me. And best of all a Sun employee said that invokedynamic would be part of Java 7. Now, that doesn't mean anything, but it is encouraging to hear that Sun is committed to getting it included in Java 7.

The surprise of the day for me was the presentation on Fan. I had not heard of fan prior to signing up for the event. It seems like it is still pretty immature, but it is interesting. The language is being created from the ground up to run on the JVM and CLR. They have spent most of their time making libraries that can be built on top of both platforms. The big problem is that you can't call out to the multitudes of libraries available on those platforms. This is a show stopper for now.

Stu's lightning talk started the best conversation of the day. The open sessions, or unconference or whatever term you prefer, were not nearly as successful at getting people talking about issues as Stu's presentation. The conversation focused on how libraries can be provided on the JVM in the best of breed language for that particular problem and just as importantly how the library can be used by other languages on the JVM. This second part is the part that there is no clear answer for right now. Clojure's collections and the regex library in JRuby were used as examples of libraries that could be shared by lots of languages implemented on the JVM.

Summary

• Hotspot - Just an intro to the event.
• invokedynamic - Read headius' blog if you'd like to know more.
• Maxine - An experimental VM. Not compliant yet. Has an API.
• Fan - new language to run on JVM and CLR.
• Groovy - Intro to Groovy
• Scala - Focused on one aspect of Scala
• Fortress - Fortran on the JVM with concurrency, lots of it. They came the most prepared to make recommendations to Sun of features that could be added to the JVM. The list contained things like continuations, value objects, etc.
• Multiple dispatch - Professor's implementation of how multiple dispatch could be done on the JVM quickly and without too much disruption.

• Identify piece(s) of code to review
• Notify reviewers
• Assign grades based on the following criteria
• Design
• Cleanliness
• Test Quality and Coverage
• Documentation
• Accuracy Against Estimate
• Simplicity
• Meets Requirements
• Working as Designed
• Positive User Experience
• Meet to discuss the grades
• Take corrective action

Comments

• The list of criteria is not set in stone or some magical list of categories. These are based on my own personal experiences. You should modify the list as you see fit for your team. For example, if performance or security is critical to your mission, then they should receive special attention!
• The categories can be weighted to stress certain areas. This can be useful if a team (NOT an individual) needs to stress one area versus other areas. The weights may change over time.
• Use a grading system that you feel best applies to your software team's practices. This can be a letter grade (A,B,C,D,F), a numerical score (1,2,3,4) or something completely different.
• The focus should be on the code and not the developer(s). This is not an assessment of team member(s), it is a review of the code after all! Therefore, do not select pieces of code worked on by a developer, rather select code related to your user stories.
• Use a tool (such as a wiki, issue tracking tool or planning tool) to track your code reviews AND technical debt that is discovered as a result of the code review.
• DO SOMETHING ABOUT IT. Many organizations conduct code reviews and little corrective action is taken. Be sure to schedule time to address issues uncovered in code reviews!

Looking for feedback!

Examples:

n == 4

1. ()()
2. (())

1. ()()()
2. (()())
3. ()(())
4. (())()
5. ((()))

His solution:

• The number n must be even
• Treat '(' as 1
• Treat ')' as 0
• The minimal value will be "10" n/2 times. ie 101010
• The maximum value will be "1" n/2 times followed by "0" n/2 times. ie 111000
• The odd parity must be n/2
• The even parity must be n/2
• The combinations must be well formed ie (()) and not ))((

The algorithm to solve the problem went like this: Say n is 8, loop from 10101010 to 11110000 by 2's (to exclude odd numbers), make sure that the even parity equals n/2 and that the odd parity equals n/2. For each number loop over the bits and add +1 for 1 and subtract -1 for 0. Throw out any number that goes below 0 at any point.

This algorithm will get you to the correct solution but the solution involved heuristics and considered some invalid combinations. I was sure that there was a way to solve this problem without considering any invalid combinations and I was right. Here is my solution (with an implementation in ruby):

Note: I would not be surprised if there is a mathematically more efficient way to solve this problem, but this is what I came up with.

1. Create a grid of all the possibilities.
2. Create a directed graph.
3. Walk the graph from the end to the beginning.

I am including four figures now that I will reference below.

Create a grid of all the possibilities. Thinking in terms of a turn based stack, the blue squares in figure A can be ruled out as invalid.

Create a directed graph. Again thinking in terms of our stack, there are only two possible operations, push and pop. So as we move from turn 1 to turn 2 we must go either up and to the right OR down and to the right. I also consider the two possible incoming points because my directed graph is bi-directional (think in terms of a doubly linked list). So for the point (0,0) we can see the four possibilities in figure B. They are (-1,1), (-1,-1), (1,-1) and (1,1). Of these four only the point (1,1) falls in a yellow square and is therefore "valid". We then move on to this point and repeat the process until we end up at point (n,0) which is always our last point. At this point our data structure looks like diagram C.

Finally, we have to walk our structure to determine all the valid combinations. My first thought was to walk from the point (0,0) to (n,0) but I ended up walking from the end to the beginning! (Either way works, but I found the code easier to write going in the opposite direction). Using the labels from diagram D we see the valid combinations are:

• J I H F D B A
• J I H E D B A
• J I H E C B A
• J I G E D B A
• J I G E C B A

And finally, the ruby code!

class DirectedBinaryGraphNode
  attr_accessor :last_lower, :last_higher, :next_lower, :next_higher, :x, :y
  def initialize(x,y)
    @x = x; @y = y
  end
  def to_s()
    "#{x}, #{y}"
  end
end

def validate_node(n,index)
  x = index[0]; y = index[1]
  width = x >= 0 and x <= n
  vertical = (x < (n/2)) ? x : (n-x)
  height = (y >= 0 and y <= vertical)
  x <= n and width and height
end

def ensure_node(index,n) 
  if ( @nodes[index] ) then
    node = @nodes[index]
  else
    node = DirectedBinaryGraphNode.new(index[0],index[1])
    @nodes[index] = node
    create_node(n,node)
  end
  node
end

def create_node(n,node)
  puts "creating node #{node}"
  last_lower = [node.x-1,node.y-1]
  last_higher = [node.x-1,node.y+1]
  node.last_lower = ensure_node(last_lower,n) if validate_node(n,last_lower)
  node.last_higher = ensure_node(last_higher,n) if validate_node(n,last_higher)
  next_lower = [node.x+1,node.y-1]
  next_higher = [node.x+1,node.y+1]
  node.next_lower = ensure_node(next_lower,n) if validate_node(n,next_lower)
  node.next_higher = ensure_node(next_higher,n) if validate_node(n,next_higher)
end

def create_data_structure(n)  
  @nodes[[0,0]] = DirectedBinaryGraphNode.new(0,0) 
  create_node(n,@nodes[[0,0]]) 
end

def walk_data_structure(str,last)
  if ( last.last_lower) then
    walk_data_structure("(" + str,last.last_lower)
  end
  if ( last.last_higher) then
    walk_data_structure(")" + str,last.last_higher) 
  end 
  unless last.last_lower or last.last_higher then
    @cnt = @cnt + 1
    puts "Valid combo: #{str}"
  end
end

n = ARGV[0].to_i
unless ( n % 2 == 0 ) then
  puts "invalid parameter #{n} [it must be even]"
  exit -1
end
@nodes = {}; @cnt = 0
create_data_structure(n)
walk_data_structure("",@nodes[[n,0]])
puts "Total number: #{@cnt}"

<project>

  <modelversion>4.0.0</modelversion>
  <groupid>com.trial.easyb</groupid>
  <artifactid>easyb-trial</artifactid>
  <version>0.1</version>

  <dependencies>
    <dependency>
        <groupid>org.easyb</groupid>
        <artifactid>easyb</artifactid>
        <version>0.8</version>
    </dependency>
    <dependency>
        <groupid>junit</groupid>
        <artifactid>junit</artifactid>
        <version>4.4</version>
    </dependency>
  </dependencies>

  <repositories>
    <repository>
      <id>easyb</id>
      <url>http://www.easyb.org/repo/</url>
    </repository>
  </repositories>
  <pluginrepositories>
    <pluginrepository>
      <id>easyb</id>
      <url>http://www.easyb.org/repo/</url>
    </pluginrepository>
  </pluginrepositories>

  <build>
    <plugins>
      <plugin>
        <groupid>org.easyb</groupid>
        <artifactid>maven-easyb-plugin</artifactid>
        <version>0.8</version>
        <executions>
          <execution>
            <goals>
              <goal>test</goal>
              <goal>storyReport</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <easybtestdirectory>${basedir}/src/test/stories</easybtestdirectory>
          <storyreport>${project.build.directory}/easyb-stories.txt</storyreport>
          <xmlreport>${project.build.directory}/easyb/report.xml</xmlreport>
        </configuration>
      </plugin>
    </plugins>
  </build>  

</project>

Pattern Matching: What is missing?

Useful error messages. Huh? Why? What are you proposing?

When all goes well

The code block associated with the case is executed. All is fine here.

When there is no match

A scala.MatchError exception is thrown. Herein lies the problem. As a developer, I get a MatchError exception with a string that says that there was a match error. If I look at the stack trace I can even figure out where things went wrong in the code. But why can't I provide the match statement a String with a more developer/user friendly error message? Why can't I say what there was no match for? For example, suppose I am matching days of the week. Wouldn't a message like "Unable to match the day of the week." be more useful then a general error simply stating that a MatchError was thrown?

When there is a type mismatch

If the data type of the thing being matched cannot be applied to any case in the match that gets executed a scala.MatchError is thrown. Since this is a different type of error I would contend that it is fine as is.

Proposed modification

What if the match was passed a string with a user/developer friendly error message? It might look something like this:

  val user = "harry"
  user match "Unable to match the name against the list of Weasley boys" {
    case "fred" =>
      println("this would not be good")
    case "george" =>
      println("this also would not be good")
    case "ron" =>
      println("again, not good")
    case "percy" =>
      println("still not good")
  }

  val user = "harry"
  user match (n) => "Unable to match the name " + n + " against the list of Weasley boys" {
    case "fred" =>
      println("this would not be good")
    case "george" =>
      println("this also would not be good")
    case "ron" =>
      println("again, not good")
    case "percy" =>
      println("still not good")
  }

1. As is :)
2. Match would take a string and use that as the message
3. Match would take a callback function and pass it the value not matched

Tuples

(1, 2.0, "three")

Case Classes

case class Foo(firstData:Int, secondData:Int)

Pattern Matching

First, pattern matching is a glorified switch statement.

x match {
  case 1 =>
    println("x is 1")
  case _ =>
    println("x is not 1")
}

val x = Foo(3,5)
x match {
  case Foo(z,5) =>
    println(z)
  case _ =>
    println("we didn't have a match")
}

Second, pattern matching is like built in assertions (well, sort of).

x match {
  case 0 =>
    println("x is 0")
  case 1 => 
    println("x is 1")
}

Third, pattern matching is useful for variable assignment

val a = (1,2.0,"three")
val (d,e,f) = a
println(d)
println(e)
println(f)

1
2.0
three

val a = (1,2.0,"three")
val (b,2.0,"three") = a
println(b)

The following example would throw an exception!

val a = (1,2.0,"three")
val (b,2.0,"3") = a
println(b)

• Do all of the bound variable values match?
• If yes, then we have a match!
• If not, what could the code do to make the statement true? (ie assign a value to an unbound variable...)

Some points of interest

Ok, so the first thing you might notice is that I have to have two explicit dependencies: jline and scala itself. maven-scala-plugin will compile your code without the scala dependency, but it cannot run the classes unless the jar is provided at runtime via a dependency. Jline I determined was required by simple trial and error.

The scala-maven-plugin site's documentation is incorrect. The group id is not "scala" as they claim, it is in fact: <groupId>org.scala-tools</groupId>

The sourceDirectory and testSourceDirectory do not have to be specified if you decide to use src/main/scala and src/test/scala (at least according to their documentation) but I have chosen to explicitly state them here anyway.

So, you need to put your scala code in src/main/scala and your tests in src/test/scala. The typical HelloWorld example could be saved to src/main/scala/HelloWorld.scala which looks like:

package org.example {
  object HelloWorld extends Application {
    println "hello"
  }
}

mvn clean compile

mvn scala:run

That small group of people are the developers who understand functional programming languages. Functional programming languages do not have shared state. This makes concurrency in them a joy when compared to Java and most OOP languages. I recently took some time to start learning Erlang (Pragmatic Studio, very well done Joe and Dave!) and I was very impressed with what I saw. I really loved some of the aspects of Erlang. It is well known for having concurrency baked into its DNA, but I was impressed with several other things (things I had seen before, but just felt so natural in Erlang). Higher order functions, list comprehensions, hot deployment, and most importantly pattern matching. This isn't an blog about any of those topics however. This is about concurrency and in the title I mentioned concurrency on the JVM.

One of the things that I did NOT like about Erlang was that the sequential programming features seemed incomplete to me coming from an OOP world. Not to mention commas, semi-colons, periods and nothing... and when to use which! I remember wishing in class that Erlang ran on the JVM so I could use it for all my concurrency needs and call out to Java/JRuby/Groovy/SISC/etc for the meat of my application logic. Using the xmerl library (I know that there is a better one out there, but c'mon no xml library should be this difficult) made me really long for something better. So once again I took a step back and tried to look at the big picture.

Before going to the Erlang Pragmatic Studio I had started to read up on Scala (which I find difficult because I find the documentation to be very sparse and fairly poor) and Scala's actor library in particular. I admit that when I first looked at it I didn't fully get it. Learning Erlang helped cement some concepts that make looking at the Actor library much, much simpler. While I still prefer the Erlang way of receiving messages in particular I found the Scala Actor library to be decent. It is also worth nothing that the Scala actor library works with threads or with processes (actors, not OS processes). To me, the whole reason to use the actor library is to NOT be using threads, so I highly recommend the event based actors.

Actor concepts

In an actor based concurrency model, there are 3 fundamental concurrency primitives. First, there is spawn. Spawn creates a new actor which has a mailbox where it can receive messages. In Erlang spawn spawns functions and in Scala the equivalent is creating a new Actor and starting it. (Think creating a new thread and starting it). The second primitive is send (!). This is pretty similar in both Erlang and Scala. receiver ! message means send message "message" to "receiver". Scala actually has some additional methods for sending messages but we won't cover them here. Finaly there is receiving messages where a message is pulled from the mailbox if it matches a pattern and can be acted upon. Erlang blows away Scala on pattern matching from what I can tell, but I am admittedly not an expert on Scala pattern matching.

So some important topics to discuss now: What is an Actor, immutable state and pattern matching, and process linking.

What is an actor?

An actor is like a thread but without shared state. I sometimes refer to it as an programming language process because an actor is a process, but not an operating system process. It is a process that is managed by the runtime process and therefore must be very lightweight. Erlang has spent a lot of time getting processes very light weight. Erlang doesn't use the term actor, it just has processes, but they are the same thing. Each process or actor has a mailbox where it receives messages from other processes. Messages are the ONLY way that processes can communicate since they have no shared state.

Immutable state and pattern matching

Immutable state is key to functional programming languages as they are intended to have no side effects and immutable state means that no function can change the value of something (a variable) and thus introduce a side effect. Pattern matching in Erlang is brilliant. It matches the left side and the right side of the =. Conceptually there are 3 things that can happen here. If the left is unbound it will be bound with the value from the right side. This looks like variable assignment from OOP. If the left side is bound it must match the value from the right side or an exception will be thrown. This is because variables are immutable and they cannot be "assigned" another value. Finally, if the left side has a partial match it can assign values to unbound variables that match the pattern. A tuple is the simple way of understanding this.

A = "a",
B = "b",
{A,C} = {A,B}

A = "a",
B = "b",
{A,B} = {A,C}

A = "a",
B = "b",
C = "c",
{A,C} = {A,B}

Fault tolerance

So if you have heard of Erlang, you have probably heard that it makes concurrency and fault tolerance easy. We've looked at the concurrency primitives, but what about the fault tolerance primitives? They are link, unlink and process_flag. These are conceptually simple. If a process A links to process B then they are linked. If one dies then it will send a signal to all the processes that it is linked to prior to its own death. The linked processes can be system processes depending on whether or not they set their process_flag. If they did then they can trap exit messages from dying processes, if not then this process will die as well. So as you can probably imagine it is easy to create graphs of processes that will die when certain failures occur and that can be restarted or resurrected by some system processes. Scala's actors have these concepts as well. I won't go into any more detail about them here, but if you read the links at the bottom of this blog you can find some additional information in the Scala actor api.

So now that I have given a very long winded ill-explained description of actors, let's look at a real example in Erlang and in Scala:

Erlang

-module (blog).
-compile(export_all).
			
client(Pid) ->
	Pid ! {self(),request,foo},
	receive 
		{Pid,response,Response} ->
			io:format("got response ~p~n",[Response]),
			Pid ! exit
	end,
	io:format("client done~n").
		
server() ->
	receive
		{From,request,Request} ->
			io:format("got request ~p~n", [Request]),
			sleep(1000),
			From ! {self(),response,bar},
			server();
		_ ->
			io:format("server done~n")
	end.
	
sleep(Time) ->
	receive
	after Time -> void
  end.

foo() ->
	Pid = spawn(fun server/0),
	spawn(fun() -> client(Pid) end),
	exit.

Scala

import scala.actors.Actor
import scala.actors.Actor._
import scala.actors.OutputChannel

case class Request(data:Object)
case class Response(data:Object)
case object Exit

class Client(server:Actor) extends Actor {
  def act() {
    server ! new Request("foo")
    react {
      case Response(data) => 
        Console.println("got response " + data)
        server ! Exit
		println("client done")
        exit()
    }
  }
}

class Server() extends Actor with Sleeper {
  def act() {
    loop {
      react {
        case Request(data) =>
		  println("Got request " + data)
          sleep(1000,(sender:OutputChannel[Any]) => {
			sender ! new Response("bar")
		  },sender) 
        case _ =>
		  println("server done")
          exit()
      }
    }
  }
}

trait Sleeper {
  def sleep(time:Long,fun:(OutputChannel[Any])=>Unit,sender:OutputChannel[Any]) {
    reactWithin(time) {
      case _ =>
        fun(sender)
    }
  }
}

object Foo extends Application {
  var s = new Server()
  var c = new Client(s)
  s.start
  c.start
  println("exit")
}

So what does it do?

This code spawns two actors, 1 as a client and 1 as a server. The server listens for request messages and responds with response messages after sleeping for 1 second. If a message comes in that is not a request message, then the server exits. The client sends a request message to the server and then listens for the response. Once it receives its response it sends a message to the server that is not a request as a shutdown command. Not particularly interesting, but it does demonstrate some of the key differences between Erlang's processes and Scala's actors. One of the biggest differences is that a receive in Scala is a method that does not return. This means that any logic must be present in the receive and all code after the receive will never be executed. Erlang can pattern match on atoms and tuples and Scala pattern matches on case classes. One of Erlang's strong points is distributed code. In Erlang, when a process is spawned there can be no knowledge of whether or not that process is running on the same machine or remotely. It simply doesn't matter. Scala has remote actors as its equivalent, but the things I've covered here so far are really for replacing threads within a single JVM. The concepts don't change and maybe that will be the topic of a future blog post.

Resources:

• Scala
  • Tutorial
• Scala Actors
  • Actors Doc
  • Actors tutorial
  • Actors Example
• Erlang
  • erlang
• Ruby Actors
  • InfoQ with MenTaLguY
  • Revactor

Update

If you did not need the sleep function, you could use this shorthand notation to define the actors. Notice that the server actor is assigned to a variable that the client actor uses.

import scala.actors.Actor
import scala.actors.Actor._

case class Request(data:Any)
case class Response(data:Any)

object Foo extends Application {

	actor {
		server ! new Request("foo")
		react {
		  case Response(data) => 
		    Console.println("got response " + data)
		    server ! "Exit"
		    exit()
		}
	}

	var server = actor {
	    loop {
	      react {
	        case Request(data) => 
	          Console.println("got request " + data)
	          sender ! new Response("bar")
	        case _ =>
	   		  println("exiting server")
	          exit()
	      }
	    }
	}

}

The most pathetic diagram you will ever see

Inputs -> Generator -> Generated

Pathetic diagram + Runtime

Inputs -> Generator -> Generated  <= Runtime