It has been on my mind for a long time, to write about this – supporting dynamic languages on the most advanced runtime on the planet. I have been having this pet project on the back of my mind, and figured that I should probably write about it now. I was wondering how hard it would be to extend the CLR in a fundamental way to support dynamic languages – the idea here is not to add a whole bloat of features to the CLR, but to try and identify a set of primitive or simple rules/abstractions which when added to the CLR would enable implementation of dynamic languages efficiently on the CLR.

Why the CLR? Because the CLR is one of the fastest runtimes/VMs out there; it was inherently designed to run multiple languages; runs on a whole bunch of hardware and software platforms and has a very wide acceptance in the industry; it is an open standard that is not owned by any company; and there are atleast two publicly available implementations in source form – which means that it enables a language that previously had to lug along its own VM/interpreter to boldly go where no previous version has gone before.

Some smart languages like Groovy are doing this with the JVM. I was hoping for a while that Ruby would – but it turns out, after several mails on the Ruby mailing list that Matz the creator of Ruby, has other plans. Matz is writing his own VM for Ruby.

It looks like it’s a season for writing multi-language runtimes – head of the pack being Parrot, the new VM for Perl 6. There is of date, little or no information available about the actual architecture of Rite – ruby’s VM that Matz is working on.

What makes a runtime that supports dynamic languages different from runtimes that are built to support statically typed OO languages – I don’t have enough of a formal education or personal experience to answer that straight out. That is one of the things that I hope to teach myself in coming time. I can throw terms like dynamic method dispatch at you… but essentially I don’t know if I can nail it down to a set of fundamental primitives that make all the difference.

This is a blog entry about some of my early ramblings on the topic. I am hoping to teach myself some of the difference by looking at the opcode design for Parrot. I am expecting that there would be opcodes for runtime type lookup, runtime method invocation etc etc – does that solve the problem, I don’t know. It provides features that can be used to mitigate the problem, yes. In conjunction with studying the architecture of Parrot, I am hoping to compare and contrast that with what the CLR supports and see what is missing in the CLR. Again I am not expecting much to be missing – what I am expecting to be seeing be seeing is that a lot of what Parrot provides as opcodes, the CLR would not natively provide, but would instead be available as framework API.

There is another source – Jim Hugunin’s IronPython. Sometime early this year Jim Hugunin shocked the Python community and a large part of the dynamic languages world by implementing a python version that ran on the CLR – it was faster that the classical C Python. Jim previously was known for his Jython – a Python that ran on the JVM – but was a rather slow implementation. What Jim has essentially done is that he has written a bunch of libraries to augment what the framework provides and has used these liberally along with regular IL. Jim now works for the CLR team at Microsoft.

Once I think I have an understanding of how the Parrot opcodes makes it a better runtime for dynamic languages, looking at Jims work (which is openly available) should give me a good idea of what primitives can be derived and can be pushed into the CLR. That should be a good fun project to work on.

A lot of what I have typed would be plain common sense for someone who was actually following the field. A whole bunch of things are getting in the way of getting started, else I would have already.