Yesterday I talked about Boo, the statically typed scripting language. I mentioned as one of the things that made it interesting that it’s a look into the future of programming languages. I also mentioned that one particular feature, namely type inference, may make it into C# (3.0?) one day, because I heard “Anders Hejlsberg”: say that a while ago during an interview. Another thing that he was interested in was closing the gap between relational (database) data and the object model.

That’s where “Comega”: (C-omega) — a Microsoft Research programming language — comes in. But not only there, these are the two major new things that Comega brings:
* A control flow extension for asynchronous wide-area concurrency (formerly known as Polyphonic C#)
* A data type extension for XML and table manipulation (formerly known as “Xen”: and as X#):

“This (older) article, talks about the control flow for asynchronous concurrency”:

In Polyphonic C#, methods can be defined as either synchronous or asynchronous. When a synchronous method is called, the caller is blocked until the method returns, as is normal in C#. However, when an asynchronous method is called, there is no result and the caller proceeds immediately without being blocked. Thus from the caller’s point of view, an asynchronous method is like a void one, but with the useful extra guarantee of returning immediately. We often refer to asynchronous methods as messages, as they are a one-way communication from caller to receiver (think of posting a letter rather as opposed to asking a question during a face-to-face conversation).

By themselves, asynchronous method declarations are not particularly novel. Indeed, .NET already has a widely-used set of library classes which allow any method to be invoked asynchronously (though note that in this standard pattern it is the caller who decides to invoke a method asynchronously, whereas in Polyphonic C# it is the callee (defining) side which declares a particular method to be asynchronous). The significant innovation in Polyphonic C# is the way in which method bodies are defined.

In most languages, including C#, methods in the signature of a class are in bijective correspondence with the code of their implementations — for each method which is declared, there is a single, distinct definition of what happens when that method is called. In Polyphonic C#, however, a body may be associated with a set of (synchronous and/or asynchronous) methods. We call such a definition a chord, and a particular method may appear in the header of several chords. The body of a chord can only execute once all the methods in its header have been called.

I studied this part about two years ago or so (when it was still called Polyphonic C#) and I think it can be quite interesting to developers who deal with asynchronous calls a lot. If you intend to fully understand Polyphonic C# I must warn you that it can be quite complicated. At least, when I studied it two years ago I thought it was complicated. But then again, that was two years ago, when I was just a little 19-year old boy.

“This article introduces the XML and database extensions”:

One of the main reasons for XML’s rise to prominence as the lingua franca for information interchange is that, unlike prior data interchange formats, XML can easily represent both rigidly structured tabular data (e.g., relational data or serialized objects) and semi-structured data (e.g., office documents). The former tends to be strongly typed and is typically processed using object⇔XML mapping technologies, while the latter tends to be untyped and is usually processed using XML technologies like DOM, SAX, and XSLT. However in both cases, there is a disconnect for developers processing XML using traditional object-oriented programming languages.

In the case of processing strongly typed XML using object⇔XML mapping technologies, there is the impedance mismatch between programming language objects and XML schema languages like DTDs or W3C XML Schema. Notions such as the distinction between elements and attributes, document order, and content models that specify a choice of elements are all intrinsic to XML schema languages but have no counterpart in standard object-oriented programming. These mismatches tend to lead to some contortions and lossiness when mapping XML to objects.

To give you a quick impression of what code using these features looks I’ll post two bits of code. The first one shows how you can use XPath expressions on data:

struct {int a; int b; int c;} z = new {a=5, b=10, c= 15};
int* values =*[it > 8]; // This is the XPath expression
foreach(int i in values) {
Console.WriteLine(i + " is greater than 8");

Comega also supports SQL queries as language constructs. Everything is strongly typed, when you want to use a database, you first let a tool convert the database schema to a .NET assembly, which contains all the types. Then you can query it like this:

rows = select ContactName, Phone from DB.Customers
order by ContactName desc, Phone asc;

There’s a lot more to this Comega language than I described here, reading the two articles that I referenced will give you much more insight. Again, it’s an interesting look into the future of programming languages.