The dotnetlanguages.net blog has released a nice review on the Lang.Net event. John Gough, pascal lover, author of ‘Compiling for the .NET Common Language Runtime’, and the one leading the ‘Ruby on the CLR’ adventure seems to share my thoughts that the CLR need to be dramatically improved to support truly dynamic languages. Excerpt from the review:
The next presentation was done by John Gough, who talked about his work implementing Ruby on the CLR. First, he covered the essentials of Ruby. This really wasn’t an introduction to Ruby per-se; it was focused on the history of Ruby. He then moved to his Ruby.NET project, which he said is a compiler, “not an interop wrapper, or a…standard interpreter”. Specifically, he talked about the problems and issues he’s run into - the main one being “there is no authorative definition of the language semantics”. In Ruby, everything is an object with a well-defined class. However, Gough warns that Ruby classes shouldn’t be mapped to System.Type as class definitions can be changed at runtime. Gough talks about their own built-in Ruby classes (e.g. Ruby.Object, Ruby.Class, etc.). The method binding issues seem pretty complex at first due as methods can be attached to one object of a given class but not another, so even though both objects have the same class, they don’t have the same features. The tree that is generated to represent a class with a mixin is quite daunting - I don’t envy the work it takes to get Ruby to work on the CLR! He mentioned that he did not use delegates to implement the methods; rather, he defined a class called MethodBody to represent every method, which he said allows for method specialization. A lot of the implementation details hint at what Jim Hugunin talked about at Compiler Lab 2006 relative to IronPython. For example, Gough mentions a “activation frame” to support closures - IronPython has a FunctionEnvironment. At the beginning of the talk, Gough mentioned that the CLR needs a standard API to support a lot of the features that dynamic languages share, and this seems like one of those. I wished Gough would’ve had more Ruby code examples - it was hard to follow his talk at times when he talked about implementation details (a good example of this is when he talked about blocks and what happens during a return - I really couldn’t figure out what he was getting at). Gough ended with the current status of Ruby.NET. It currently does not have support for continuations and threads, although he states it passes “all 800-odd tests of the basic test suite”. He said there’s currently lots of room for performance gains, but right now his group hasn’t spent a lot of time on performance tweaking. He also mentioned some spin-off projects/tools from Ruby.NET, like a PE-file reader/writer (PERWAPI), a C# parser generator (GPPG), and a scanner generator which emits C# (GPLEX).
Now, Microsoft, the ball is in your court.
