The IronRuby team is busy moving forward on both the Ruby implementation and the underlying Dynamic Language Runtime (DLR). The latter is a group of various APIs and systems all (dynamic) language implementations for .NET (might) need. By pulling out this functionality into a common library, creating new language implementations will become much easier. A new blog about the using the DLR to build language implementations now provides practical insight in the design of the DLR.
An example is how the DLR factors out IL code generation:
The blog, written by Martin Maly who works at Microsoft on IronPython and the DLR, uses a toy language, conveniently named ToyScript, to show basic principles of the DLR. Future topics will also focus on how the DLR is used in IronPython or IronRuby.
This project also shows the kind of services a common language runtime library can provide - a similar project called JLR was attempted for the Java platform. While the JLR project seems mostly abandoned (with only one library in the SVN repository), the accompanying JVM Languages list is busy and shows that language implementations for the JVM face very similar design issues.
As for general IronRuby progress, read InfoQ's recent John Lam interview.
An example is how the DLR factors out IL code generation:
The ToyScript sample language's front-end is very similar to that of any traditional compiler. It has tokenizer, parser and an abstract syntax tree representation of the toy language. What makes it a DLR based language (from the compiler pipeline perspective) is that instead of generating its own intermediate code, or generating Microsoft .NET IL directly, ToyScript will generate a tree representation of the code - DLR Trees. Dynamic Language Runtime will then take care of the code generation.
The DLR Trees are essentially the DLR representation of programs so every language that targets DLR produces the DLR Trees. ToyScript's design is similar to that of all the other DLR based languages, such as IronPython or IronRuby in the sense that it first parses into its own AST and then generates the DLR trees. At one point ToyScript (being very simple language) parsed directly into the DLR trees, but we changed that to behave more like the other DLR based languages, even though for ToyScript it is not strictly necessary.
By generating the DLR Trees instead of IL, the compiler writer doesn't have to worry about the IL generation and the DLR will take care of the intricacies. The developer can then focus on the correct semantic of the language at hand by implementing the front-end and implementing the correct runtime semantic.
The blog, written by Martin Maly who works at Microsoft on IronPython and the DLR, uses a toy language, conveniently named ToyScript, to show basic principles of the DLR. Future topics will also focus on how the DLR is used in IronPython or IronRuby.
This project also shows the kind of services a common language runtime library can provide - a similar project called JLR was attempted for the Java platform. While the JLR project seems mostly abandoned (with only one library in the SVN repository), the accompanying JVM Languages list is busy and shows that language implementations for the JVM face very similar design issues.
As for general IronRuby progress, read InfoQ's recent John Lam interview.