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.