Jb in a nutshell

Two days ago, I was sharing what I was foreseeing for C# 4 and .net 4, and the integration with the DLR.

Turns out that today, by reading this post, my eye was caught by the namespace I was thinking about: System.Scripting.

But this post is about the beta 4 of IronPython 2, that hasn’t been released yet. But heh, it’s easy to forget that latest IronPython code can be downloaded from CodePlex’s TFS.

And it indeed turns out, that in the latest revision, Microsoft.Scripting.Core namespace has been renamed to System.Scripting, and that the DLR AST has been merged into System.Linq.Expressions.

So yeah, I guess we can safely admit that C# 4 will have statements support inside expression trees.

And that .net 4 will contain very cute features for dynamically generating programs, without resorting to emitting plain IL, simply using the DLR, contained in a new assembly (or namespace, if they move some to parts to System.Core), System.Scripting.

UPDATE: turns out that there’s some true in those previsions, a small follow up.

I’ve been thinking a bit about the discussion in this video, about the future of C#, and specifically about its next version. If nothing is said clearly and loudly, as they’re most probably waiting for the PDC, you can still get a glimpse of what C# 4 and .net 4 will get as new features.

I’m mostly interested in one aspect of those new features. It’s the possible integration of the DLR inside the framework, and in the C# language.

The DLR, as we used to have it in IronPython, has been split into two separate assemblies, Microsoft.Scripting, and Microsoft.Scripting.Core a few months ago.

Microsoft.Scripting.Core is probably the part that will make it into the framework. It’s the part that contains a generalist AST, a compiler for this AST, using both LCG and traditional SRE for the debug scenarios. It also comes with a fast dynamic call site implementation, and an hosting API. So are we going to have a new System.Scripting assembly?

An interesting change in the DLR, is the naming of the AST factory and nodes. I’ve spent the last months working on LINQ and the LINQ compiler in Mono, and comparing the LINQ expression AST with the DLR AST is an interesting thing to do.

The DLR AST is now basically the LINQ expression AST, with statements added. And it looks like the current DLR AST has been tinkered around what has been already shipped inside .net 3.5 in the namespace System.Linq.Expressions.

Here’s a small example. In System.Linq.Expressions, pretty much all node from the AST extends the type Expression. Each Expression has a NodeType property, of type ExpressionType.

And you can find the same thing now in the DLR, but with some stuff added.

public enum ExpressionType {
    // some traditional expressions

    Add,
    AddChecked,

    // ...
    Call,

    // ...

    IfStatement,
    SwitchStatement,   

    // ...
}

So for the DLR, a statement is an expression. It makes kind of sense for a dynamic language you’ll tell me, but it looks a bit weird to be implemented this way.

Anyway, C# 3 already has a way to create expression trees to support some basic meta programming features, I guess we can only wonder if C# 4 will extend the meta programming features to support not only expressions but also statements, using the DLR tree.

I have no idea how they’ll deal with the fact that the existing stuff is in System.Linq.Expressions. Are they going to obsolete the whole namespace, and redirect everything to a possible System.Scripting.Ast (sounds less likely)? Are they moving the DLR AST to System.Linq.Expressions (sounds more likely)? Who knows? Not me (I’ve never lost control).

Interesting speculations anyway :)

So for now, the only change I can foresee for C# 4, is that you’ll be able to get full code blocks instead of only expressions when asking for an Expression of T.

But here’s another interesting one we can have a glimpse here, is duck typing support based the DLR.

At the language level, it’s difficult to say if they’re going to rely

• on a dynamic code block, like the example shows in this blog entry,
• on a custom marker type,
• on another syntax for message passing to dynamic objects,

All in all, it looks like C# 4 will have some nifty stuff, let’s wait for the PDC.

Today folks at db4o released Sharpen, an open source Java to C# converter.

Am happy to see this coming, as it is soming I’ve pushed strongly for when I was working at db4objects, and was hacking on it, mentored by its main developer, Rodrigo. There I had the chance to improve the generated code, to make it look like hand written code, that follows .net conventions.

It’s nothing magic, and requires compromises on both the Java and the generated C#, but it’s pretty handy, easily hackable, and all in all, damn useful.

Rodrigo wrote a nice tutorial on Sharpen.

Time to port your Java applications to the amazing Mono!

For the fourth time, Mono has been accepted as a mentoring organization for Google’s Summer of Code.

I started contributing to Mono at the end of 2004, and I was lucky to be accepted as a student for the very first Summer of Code during the 2005 summer. And I was even luckier to be accepted again the year after. This year, just like the year before, I’m a possible mentor.

The Summer of Code is an amazing opportunity for young developers to be involved in a FOSS project, to learn, to practice programming on exciting projects, while being surrounded with talented peoples. And also to have a great summer. And to get a cool t-shirt.

Oh, and for what it’s worth, five students (including me) from the previous SoC editions are now employed by Novell to work on Mono or Moonlight.

So yeah, if I had an advice, that would be to go have a look at the proposed tasks, you can even submit your own original proposal if you think you have a bright idea, and apply for it. You have three days.