Compiler Dev Lab
The DLR team is hosting this year's compiler dev lab on campus this week. One of the really cool things about the lab was meeting folks who were really interested porting their languages to run on top of the DLR.
It was fun hanging out with Miguel de Icaza again - and Miguel's been posting his notes from the first two days of the dev labs on his blog.
John Gough was also there - and we had a great time talking about Ruby and some of his latest projects.
I had a fun time chatting with Rodrigo de Oliveira from the Boo project - a Python-esque statically typed language with optional dynamic typing. Rodrigo was really interested in porting Boo to run on the DLR because of the potential performance benefits of our dynamic dispatch mechanisms. Also there was JB Evain of Cecil fame, who was recently hired by Miguel to work on Mono over at Novell (congratulations on the new job!). These two guys are doing a fantastic job of building a very nice static language compiler platform that layers on top of the CLR (should you guys call it the Static Language Runtime? :))
A nice side effect of the lab is that it forces us to start documenting parts of the DLR. I'm going to be spending some time writing up our talk from the dev lab, but for folks who want some more detailed information about the DLR, here's the slides from the talk that I gave today with Nandan Prabhu (one of the JS compiler devs) and Dino Viehland (one of the IronPython / DLR compiler devs).
Update: I've managed to grab a copy of Jim Hugunin's deck from his Zen of the DLR talk on Monday. We're recording all of the talks here, so I'll post them somewhere when we've done the post-production pass on them.
Very interesting. If all that code is running on the DLR already, I am really impressed. I am also dying for Ruby bits!
Hard to comment on much, but I did see some things that worried me:
1) Converting an Int32 value to an object when assigning it
2) Calls to RubyOps.Invoke with method names in strings.
3) The interop also looked a little dodgy because it didnt seem to be calling the .NET classes directly but going through another invoke layer.
Of course it's hard to form much of an opinion from slides alone. I can't wait to see more!
Posted by: Justin | May 23, 2007 at 01:22 PM
1) Unless we can do static analysis, we're going to have to deal with boxed integers. What's cool about RuntimeHelpers.Int32ToObject is that it caches a set of pre-created boxed integers to reduce pressure on the GC.
2) is going to be fixed. If you look farther at the DynamicSite part of the talk, you'll see where the Ruby implementation is going. Dynamic sites perform call-site method caching, and give excellent performance. Our InvokeMethod hack was done just to get things up and running as fast as possible.
3) Interop needs to take into consideration the fact that the type of a can change at any time - you're seeing DynamicSite invocation here.
If you want to see the source code, just download IronPython 2.0 Alpha bits from CodePlex.
Posted by: John Lam | May 23, 2007 at 10:31 PM
Nuts! I didn't know this was going on. I'm here at MS and working on a Scheme for the CLR. I would love to see more about the DLR up close and personal from guys doing it.
Posted by: Jay Kint | June 01, 2007 at 01:40 PM