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.
JS = require '3DText.js'
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.
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:attributesopt 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.
Their new ECMAscript implementation is more of a DLR citizen and true in spirit of it.