The One True Object (Part 1)
I'm very excited by the level of interest that I'm seeing from folks who want to better understand what the DLR is all about. I'm also sorry that we don't have a fully documented detailed story for you today. If you want a detailed whitepaper and documented APIs, you're going to have to wait a while. If you're happy with source code and blog entries, then you can start messing about today. And if you just want to play with working code, download the silverlight bits and start exploring what you can do on top of the DLR with Python and JavaScript together today.
I'm starting my design notes blogging today with my first entry on the dynamic type system that is one of the three key components in the DLR - and the one that I think is most important. The corner-stone of the DLR is support for a shared dynamic type system. This lets these dynamic languages easily and naturally talk to each other and share code. Equally important is that we want these dynamic languages to be able to work with the existing powerful static languages on the platform such as VB.NET and C#. We want to ensure that the huge wealth of both existing and to-be-written libraries designed for .NET all just work from dynamic languages. There's a standard pattern for achieving this kind of interoperability through wrappers and marshaling layers. Here's the pattern as I implemented it for Jython - Python running on the JVM.
Notice that with this pattern that the Python types exist in their own little world (they are in orange) and for every underlying type I need to put the objects into a Python-specific wrapper. This standard pattern is okay if you're only interested in supporting a single language. In my example above, so long as I'm only writing Python code then all of my objects will be PyObjects and they'll all work great together with all the Python-specific information on them. Where this pattern really breaks down is when you want to support integration with multiple languages. In this case every time an object moves from one language to another it needs to be unwrapped from the source language and then rewrapped appropriately for the destination. This can obviously have performance issues as these wrapper objects are created and discarded for any cross-language calls.
The wrapper approach can also have deeper problems. One challenge is just to figure out what object to pass. For example, if Python has a PyString and it calls a C# function that expects an Object, should it pass the PyString or should it unwrap it into a String? These kinds of subtle type issues never have a good answer. Even worse are the nasty problems that can be caused by loss of object identity when objects are silently wrapped and unwrapped behind the programmers back.
This wrapper pattern is also the same one used by most of the popular dynamic languages implemented in C as well. When implementing a dynamic language in C, these kinds of wrappers make a lot of sense because a C pointer doesn't have any useful runtime type information so you need to decorate it with a layer that can provide the runtime type information that's needed. However, managed runtimes like the CLR provide rich type information for their standard objects, so it should be possible to use those objects directly without the confusion and cost of wrappers and marshalling. We exploit this in the DLR, and this is the type system that we actually use.
This means that all of the objects in the DLR are exactly the same as the objects in the CLR. We're adding capabilities to better support common dynamic operations, but we're still deeply rooted in the powerful existing libraries and languages on .NET. We need to have a single unified type system without marshaling and wrapper layers between our languages if we're going to have truly seamless integration between them.
Now that I've reached the end of this first entry, I fear that it might be a little unsatisfying. All that I've explained so far about the dynamic type system is that it uses exactly the same objects and metadata that are already used by the statically typed objects already running in the CLR. Well, I'm not going to let that stop me from pushing this to the web today. More details about how we get a dynamic type system into the CLR without wrapper layers will have come next.
Comments
Anonymous
May 02, 2007
Hello Jim, First, great work! I have a question: it has been mentioned in several places that DLR's source code is part of ironpython 2.0 a1. I have downloaded the code, but not sure which part is DLR. Can you do a quick overview of the package? Thank you.Anonymous
May 02, 2007
Interesting. That first diagram reminds of the way PowerShell currently works - where everything derives from PSObject. Which leads to the obvious question - should we expect to see a new version of PowerShell built on the DLR?Anonymous
May 02, 2007
Hello Jim, I just wanted to let written down I got no unsatisfaction when reading your entry, quite the contrary. DLR looks awesome. Great job! Regards, MarcosAnonymous
May 03, 2007
Microsoft.ScriptingAnonymous
May 03, 2007
I've learned a lot of things from a lot of people in my life. The following lesson/acquired knowledge came, more than likely unbeknown to him (it was a very casual conversation, so there is no reason he would have thought...Anonymous
May 05, 2007
Dynamic Language Runtime(DLR)。DLR和IronPython全部开源，如果你微软这样的动作吃惊,请看看Microsoft 的 OpenSource Licence,可以到codeplex下载。新的动态语言运行时（Dynamic Language Runtime，DLR）向CLR中加入了一小部分核心特性，使之得到显著改善。它向平台中加入了一系列明确为动态语言需求所设计的服务，包括同享的动态类型系统、标准托管模型（Standard Hosting Model），以及轻松生成快速动态代码的支持Anonymous
May 06, 2007
Jim Hugunin's Thinking Dynamic has a series of blog entries on a new level of support for dynamic languagesAnonymous
May 07, 2007
It's time for a New and Notable Update when my flagged posts in FeedDemon gets past a screenfullAnonymous
July 02, 2007
微软在宣布了动态语言运行时（Dynamic Language Runtime，DLR）之后，到处都开始沸沸扬扬起来，Java领域也不能幸免。有不少人看起来已经相信，DLR使得.NET平台在和JVM的大比拼中先胜一筹了，原因是DLR已经解决了许多Java才刚刚开始意识到的问题。现在让我们一起来审视一下对动态语言支持的现状，以及和DLR的对比。Anonymous
July 02, 2007
当.NET在2000/2001年第一次发布的时候，Java社区认为它仅仅是从语言以及标准库上对Java的一个“克隆”。我们把二者的简单实例代码进行比较以后就可以很轻易地得出这样一个感受。不过，微软从它多年的Java经验中获益匪浅，并且成功解决了一些Sun现在才后知后觉的问题。Java社区也有人开始认为，.NET和CLR要比Java发展得更加快速。Anonymous
December 11, 2007
It's time for a New and Notable Update when my flagged posts in FeedDemon gets past a screenfullAnonymous
December 02, 2008
It's time for a New and Notable Update when my flagged posts in FeedDemon gets past a screenfull. Hurry, hurry before Iteration Planning starts... IronRuby/DLR/CLR John introduces IronRuby here and collects opinions here Meanwhile Jim posts on the video