ScalaDBC, the generic database library for Scala is more or less working. Well, actually it is working as far as I can tell, but I haven't put it through any serious testing (special cases etc.). There are two things that need to be finished though:

1. Automatic type conversion of database types to native Scala types using views. Bug #449 is a problem here, but I can't quite understand how and why.
2. A factory (and I mean a real hard-core factory) to write statement (queries) AST in a nice way. This is already partially working (one can write "selectBag fields ("a", "b" as "c") from ("a" join "b")") but it isn't supporting quite enough of the SQL standard to be useful yet. Currently, I'm stuck with a bug that might be a Scala bug, but I still have to track it down to be sure.

ScalaDALL is the name I am giving to the database library using for-comprehensions and specific optimisations that is the next task after ScalaDBC. I have started some exploratory work for this as I was really getting frustrated with the bugs that where hindering the advance of ScalaDBC. But there isn't anything really working yet.

Otherwise, I also did a little poster that you can find next to my office's door.

The current version of the library is useable, but there are at least two things that I think should be improved if one wants to use it in real applications:

• Allow more user control on the way the wait time before a retry is calculated — as this is key to the performance one will get. This could be done by supporting "pluggable wait policy" for example.
• Implement an even more optimistic policy that does not lock variables at all, but instead calculated the entire locked section as if it was alone, and only once this is done, just before committing, test whether some other thread was messing around with the data.

For them, a database interface library or language is interesting if one of the following behaviours are better than what currently exists. But in all cases, a decrease in performance is a show-stopper.

• Complexity of code is demonstrably reduced. But cleaner code with the same complexity is a no-show. Of course, in that case, they are not really interested in the problem itself but rather the result.
• Performance (in an arbitrary definition) somehow increases. For large systems, and in particular distributed systems, performance becomes an overwhelming problem and offering something that solves or mitigates this would be very useful.
• And a particular instance of performance that interest them particularly: make middle-ware programs simpler. That means that some of the processing done currently in the middle-ware program at run-time might be done at compile time by looking at the queries. An example of such processing is to find the intersection between queries (used for efficient locking of data). Tackling this problem as such is very specialised and not really in my field though.

I have also started implementing the library for the database access that will be optimised à la SLinks. Of course, it is quite uninteresting by itself without the changes to the compiler to support its optimisation. But there is a start for everything. Plenty of work remaining for this though.

val x = new atomic.Variable[Int];
val y = new atomic.Variable[Int];
val z = new atomic.Variable[Int];
x.value = 1; y.value = 2;
(for (
  val a <- x.get();
  val _ <- z.put(a);
  val b <- y.get();
  val _ <- x.put(b);
  val c <- z.get();
  val d <- y.put(c);
) yield d) run

The problem now is that the for loop as a monad is something that I find very difficult to get an intuition about. I have a very simple version that locks down the entire program when evaluating the atomic bloc, but this is of course hopelessly inefficient. But when I try to improve from this basic version, I am having troubles grasping how things interact around this comprehension/monad, and getting the right intuition on how to do it. Please, read on for a small explanation on the locking mechanisms I intend to add.

Very shortly: I started my PhD at the laboratoire des méthodes de programmation (LAMP) at the EPFL in Lausanne under the supervision of Prof. Martin Odersky on the fourth of April 2005. Currently, I intend to work on how to support relational database querying in a completely transparent (that is without SQL) yet efficient (that is with SQL) way in modern programming languages. The project might quickly extend to include more general querying for a variety of data repository systems (who said XQuery?). The modern programming language that will be used as a reference here is the LAMP's very own language, Scala.