Dynamic Language Runtime

The presentation by Jim Hugunin and John Lam on the Dynamic Language Runtime (DLR) was a great introduction for the general public on what they are trying to do.

They showed their Ruby compiler consuming JavaScript and Visual Basic code from a single program: In the above example, Ruby has been extended to allow importing modules, for instance

	JS = require '3DText.js'
	

Imports the code that does 3D transformations (written in Javascript) into the constant JS. To access functions in that javascript module, you just prefix the call with JS, like show on the screenshot (JS.playAnimation for example).

The Dynamic Language Runtime augments the Common Language Runtime and is made up of a few chunks:

• A shared type system for dynamic languages.
• A shared AST that can be used by language developers to create new dynamic languages.
• Helper/utility routines for compiler developers.
• A common hosting interface, to embed the general purpose scripting language interface into your program, and allowing developers to extend applications with one or more dynamic languages.
• Console support, they even have a simple console interface for doing interactive programming.

Today Jim has a post describing in more detail the shared type system:

They demonstrated the DLR Console, a sample application written in IronPython that allows developers to interactively write and test their code for Silverlight.

You can watch the presentation here.

Variables and functions declared in one language are automatically visible to the other languages, and by clicking on the language at the bottom of the screen programmers can switch between languages on the same session.

My photo did not come out very clear, but in this shot you can see vb, javascript and ruby. The popit routine written in VB, the event wired up in Javascript, and another event wired up in Ruby: An interesting feature of the DLR is that they added a mapping system for function names, so that code does not feel alien in other programming languages.

So the event MouseLeftButtonDown from the CLR is exposed to NRuby as mouse_left_button_down in Ruby, here you can see auto-complete when running under the Ruby context: Those properties in .NET are capitalized.

Various technical details appear on this interview by Darryl Taft:

Hugunin: In many ways, all the DLR does is it takes these things that we did custom for IronPython and it makes them work for a broad spectrum of languages. So instead of having a Python type system we now have a dynamic type system. So any language that has dynamic operations can share them

The DLR and Mono

As usual, Hugunin's team keeps exposing bugs in our compiler. For example, we did not notice when C# 2.0 came out that the operator declaration grammar now allowed for attributes on operator parameters:

operator-declaration:

attributes_opt operator-modifiers operator-declarator operator-body

That one is fixed on SVN, but am not sure its worth backporting to the 1.2.4 branch. Another issue seems to be a case of not implementing fully method group conversions as the code seems to be comparing a delegate variable against a method and we barf on that one. A simple fix for now is to merely do a manual conversion in the source "new DelegateType (Method)".

I did not research this one yet, but plan on doing that today.

The final issue seems to be an issue with the operator priorities, our compiler does not like expressions like this:

type t = var as TypeName ?? dingus;

A temporary fix for now is to put parenthesis around "var as TypeName". It should be an easy fix

With those fixes you can get the DLR building on Mono, I have not tried the rest of IronPython as am just freshly unpacked from Vegas.

JavaScript

Deepak Jain pointed out by email that the Javascript support in the DLR is their new engine, and not a research prototype.

This new Javascript implementation is following the steps of IronPython: to be true to the original language without .NET extensions. So this is different than JScript.NET that added a bunch of extensions to be a CLR citizen.

Their new ECMAscript implementation is more of a DLR citizen and true in spirit of it.

Ruby, Python and the DLR are released under the MsPl, and it would be great if they also did this for Javascript.