Sam Ng's Blog : DLR

Dynamic in C# II: Basics

samng — Mon, 03 Nov 2008 02:53:32 GMT

Last time, we began to dive into dynamic binding in C# and what happens through the pipeline. This time, we'll take a simple scenario and pick apart the details of what happens under the covers, both during compile time and runtime.

We can break down what the compiler does into three parts: type and member declarations with dynamics (ie methods that return dynamic), binding and lookup, and emitting. We'll deal now with the binding aspects of dynamic.

Dynamic binding

Dynamic binding itself can be broken into two scenarios. Lets consider the following example.

static void Main(string[] args)
{
    dynamic d = 10;
    C c = new C();

    // (1) Dynamic receivers.
    d.Foo(); // Call.
    d.PropOrField = 10; // Property.
    d[10] = 10; // Indexer.

    // (2) Statically typed receivers (or static methods)
    //     with dynamic arguments.
    c.Foo(d); // Instance method call.
    C.StaticMethod(d); // Static method call.
    c.PropOrField = d; // Property.
    c[d] = 10; // Indexer.
    d++; // Think of this as op_increment(d).
    var x = d + 10; // Think of this as op_add(d, 10).
    int x = d; // Think of this as op_implicit(d).
    int y = (int)d; // Think of this as op_explicit(d).
}

Consider the first set of examples under (1). Each of these dynamic invocations happen off of the dynamically typed expression. It is clear where the dynamicity (yes, I like that word, even though it isn't one...) comes from, and where it goes.

The second set of examples under (2) are a little more complex. The use of dynamic is indirect in each of these. Because the argument to each operation is dynamic, they flow into the containing operation and make them dynamic as well. As such, the compiler does sort of a mix of dynamic binding and static binding - it will use the static type of the receiver to determine the set of members to overload on, but will use the runtime types of the arguments to perform overload resolution.

The first set of examples are much more straight forward to understand, so we'll use this set as our foundation for exploring the feature.

Dynamic receivers

When the compiler encounters an expression typed dynamic, it knows to treat the subsequent operation as a dynamic operation. Whether its an index get, index set, method call etc, the result type of the operation will be determined at runtime, and so at compile time, the result of the operation must also be dynamic.

The compiler transforms all dynamic operations into what we'll call a dynamic call site. This consists of creating a compiler generated static field on a generated static class that stores the DLR site instance for the invocation, and initializing it as necessary.

The DLR call site is a generic object that is generic on the delegate type of the call. More on how this delegate gets generated later. The type names may not be final yet, but currently the creation of the DLR call site takes a CallSiteBinder which is an object that knows how to perform the specific binding that is required for the call site. The DLR provides a set of standard actions that can be used to take advantage of the DLR's support for interop with dynamic objects (more on that in a later post).

The call site contains a field of type T that is an instance of the delegate type that the site is instantiated with. This delegate is used to contain the DLR caching mechanism which you can learn about on Jim Hugunin's blog. It stores the results of each bind and is used to invoke the resulting operation.

Once the call site has been created, the compiler then emits the code to invoke the delegate, passing it the arguments that the user passed to the call site.

What happens at runtime?

Once the compiler has created the DLR call site, it then invokes the delegate, which causes the DLR to do its magic with interop types, and its magic with caching. Assuming that we don't have a true IDynamicObject and we don't have a cache hit, the CallSiteBinder that we seeded the DLR site with will be invoked. C# has its own derived CallSiteBinders that will know how to perform the correct binding, and will return an expression tree which will be merged into the DLR call site's target delegate for caching.

The current caching mechanism simply checks exact type matches on the arguments. For example, suppose our call looks like the following:

arg0.M(arg1, arg2, ...);

And suppose our call has arg0.Type == C, and all the arguments passed to the call are of type int. The cache check would look like the following:

if (arg0.GetType() == typeof(C) &&
    arg1.GetType() == typeof(int) &&
    arg2.GetType() == typeof(int) && 
    ...
    )
{
    Merge CallSiteBinder's bind result here.
}
... // More cache checks
else
{
    Call the CallSiteBinder to bind, and update cache.
}

C# CallSiteBinder creation

The last thing we need to paint a full picture of dynamic binding is to understand what the C# CallSiteBinder implementation does.

In our example, we have 3 different types of dynamic operations. We have a call, a property access, and an indexer. Each of these operations have their own unique pieces to them, but still share much of the common functionality. As such, they all are initialized with a common C# runtime binder, and are used by the runtime binder as data objects that describe the action that needs to be bound. We'll call these objects the C# payloads.

A good way to think of the C# runtime binder is a mini compiler - it has many of the concepts you'd expect in a traditional compiler, such as a symbol table, and a type system, and much of the functionality as well, such as overload resolution and type substitution.

Lets use the simple example of d.Foo(1) for our consideration.

Once the runtime binder gets invoked, it is given the payload for the current call site, and the runtime arguments the site is being bound against. It takes the types of the all the arguments (including the receiver) and populates its symbol table with those types. It then unpacks the payload to find out the name of the operation it's trying to perform on the receiver (in this case, "Foo"), and uses reflection to load all members named "Foo" off of the runtime type of d, putting those members into its symbol table.

From there, we have enough information in the binder's internal system to do the binding that the action describes. At this point, we fork off and bind based on the payload's description.

One of the design choices we made was that the runtime binder should have the exact same semantics that the static compiler has. This includes reporting the same set of errors that the compiler would produce, and perform the same set of conversions (user-defined or otherwise).

As such, each payload is bound exactly as the static compiler would have. The result of the bind is an expression tree that represents the action to take if the binding was successful. Otherwise, a runtime binder exception is thrown. The resulting expression tree is then taken and merged into the call site's delegate to become part of the DLR cache mechanism, and is then invoked so that the result of the user's dynamic bind gets executed.

A slight limitation

As I mentioned, we tried to keep the philosophy of matching exactly what the static compiler would do. However, there are several scenarios that will not work in Visual Studio 2010 that we will hopefully get to in a future release.

Several to note are lambdas, extension methods, and method groups.

Because we currently do not have a way of representing the source of a lambda at runtime without a binding, dynamic invocations that contain lambdas produce a compile time error.

Also, because we don't currently have a way of passing in using clauses and scopes during runtime, extension method lookup will also not be available for this next release.

There is currently no way to represent a method group at runtime (ie there is no MethodGroup type), and so without introducing that concept into .NET, there is no good way for us to allow method groups to be represented dynamically. This means that you cannot do the following:

delegate void D();
public class C
{
    static void Main(string[] args)
    {
        dynamic d = 10;
        D del = d.Foo; // This would bind to a method group at runtime. 
    }
}

Because we cannot represent method groups at runtime, a runtime exception will be thrown if the runtime binder binds d.Foo to a method group.

Hopefully you have a better understanding about the details of what happens when C# performs a dynamic bind. Next time we'll take a look at the second set of scenarios we discussed today. We'll also introduce the Phantom Method, and describe what it does and see how it affects overload resolution.

Until then, happy coding!

Dynamic in C#

samng — Thu, 30 Oct 2008 00:59:42 GMT

The other day I was playing around with some office code, and I found myself writing a lot of code much like the following sample that Anders used at his PDC talk:

static void Main(string[] args)
{
    var xl = new Excel.Application();

    ((Excel.Range)xl.Cells[1, 1]).Value2 = "Process Name";
    ((Excel.Range)xl.Cells[1, 2]).Value2 = "Memory Usage";
}

As you can imagine, it very quickly became tiresome assigning the results of each call to a local variable, debugging and finding out what type it returns for my scenarios, making the cast to the strong type so that I can call certain methods on it, rinse, and repeat.

This pattern is common in dynamic APIs, and cause a lot of excess code to be written that essentially is used just to make the type system happy. Wouldn't it be nice if instead, we could write something like this?

static void Main(string[] args)
{
    var xl = new Excel.Application();

    xl.Cells[1, 1].Value2 = "Process Name";
    xl.Cells[1, 2].Value2 = "Memory Usage";
}

Well, in C# 4.0, we now allow you to write exactly that. One of the main features that we're working on in C# 4.0 is the dynamic late binding feature. This feature allows you to tell the compiler that the thing that I'm returning really ought to be treated like a dynamic type, and that any dispatch on it should be done dynamically. The runtime will then do the binding for you based on the runtime type of the object instead of the static compile time return type, and if the binding succeeds, then the code will succeed. This gives us exactly what we want.

So how does this feature work?

Firstly, we've introduced a dynamic type into the type system. This type indicates to the compiler that all operations based on the type should be bound dynamically and not at compile time. Secondly, we've created a C# runtime binder which does the late binding for you. Lastly, we've baked in the usage of the DLR and are making full use of their caching and dynamic dispatch capabilities, so that you can interop with dynamic objects (objects created from Iron Python for instance).

The dynamic type

In order to start using the dynamic binding, we've got to have some way to signify to the compiler that we want our object or expression to be bound dynamically. Enter the dynamic type.

The dynamic type is just a regular type that you can use in your code to denote local variables, fields, method return values etc. It tells the compiler that everything to do with that object or expression should be done dynamically. Consider the following example:

static void Main(string[] args)
{
    dynamic d = SomeInitializingStatement;

    d.Foo(1, 2, 3); // (1)
    d.Prop = 10; // (2)
    var x = d + 10; // (3)
    int y = d; // (4)
    string y = (string)d; // (5)
    Console.WriteLine(d); // (6)
}

In this example, each of the statements has some element of the dynamic type flowing through it, and is therefore dispatched dynamically. Lets consider each of them.

Since the receiver in this example is typed dynamic, the compiler will indicate to the runtime that it needs to bind some method named "Foo" on whatever the runtime type of d happens to be, with the arguments {1, 2, 3} applied to it.
This example also has a dynamic receiver, and so the compiler indicates to the runtime that it needs to bind a property-looking-thing (could be a field or property) named "Prop", and that it wants to set the value to 10.
In this example, the operator "+" becomes a dynamically bound operation because one of its arguments is dynamically typed. The runtime then does the normal operator overload resolution rules for "+", finding any user-defined operators named "+" on the runtime type of d, and considering that along with the regular predefined binary operators for int.
In this example, we have an implicit conversion from the runtime type of d to int. The compiler signifies to the runtime that it should consider all implicit conversions on int and on the runtime type of d, and determine if there is a conversion to int.
This example highlights an explicit conversion to string. The compiler encodes this cast and tells the runtime to consider explicit casts to string.
In this example, despite the fact that we're calling a statically known method at compile time, we have dynamic arguments. As such, we cannot perform overload resolution correctly at compile time, and so the dynamic-ness of d flows out to its containing call, and we end up dispatching Console.WriteLine dynamically as well.

There are several other scenarios that dynamic flows out to, but I've listed these to give you a general idea of what the dynamic type's implications are.

Now, we should note that the dynamic type is really just syntactic sugar to signify to the compiler that it should treat bindings dynamically. In metadata, dynamic is just object with an attribute signifying its dynamicity (if that's even a word... I don't think it is though!).

What happens at compile time?

For each dynamic operation, the compiler generates calls into the DLR, and takes advantage of its call sites. For more information about the DLR and what call sites are, my colleague Jim Hugunin gave an excellent talk at PDC about it - you can view his blog here, and watch his talk here.

The DLR call site takes a set of standard actions which indicate what type of dynamic action we want to take. The C# compiler emits a subclass of these standard actions, annotated with some C# specific details, and emits invocations of the call sites in place of the call that the user makes. For instance, this code sample gets translated into something like the following pseudocode:

// This code...
static void Main(string[] args)
{
    dynamic d = SomeInitializingStatement;
    d.Foo(1, 2, d);
}

// transforms into this code.
static void Main(string[] args)
{
    dynamic d = SomeInitializingStatement;
    _csharpCallAction = new CSharpCallAction("Foo");
    _dlrSite<T> = new Site<T>(_csharpCallAction); // Create the site. 
    _dlrSite.Target(1, 2, d); // Invoke the delegate. 
}

If you want more information on this, my colleague Chris Burrows has written an excellent blog on the dynamic type and what the compiler generates.

Note that the site creation pseudocode specifies a generic argument, T. This argument is a delegate type that represents the signature of the call. So in our example, our call takes 2 integer arguments and a dynamic argument, and has a dynamic receiver. T would then be a delegate that represents that.

Invoking that delegate invokes the C# runtime binder, which binds the expression based on the runtime types of the arguments and the receiver.

What happens at runtime?

When the DLR delegate gets invoked, it does a couple of cool things that I'll describe briefly. For more information, check out Jim Hugunin's blog.

The DLR checks a cache to see if the given action has already been bound against the current set of arguments. So in our example, we would do a type match based on 1, 2, and the runtime type of d. If we have a cache hit, then we return the cached result.
If we do not have a cache hit, then the DLR checks to see if the receiver is an IDynamicObject. These guys are essentially objects which know how to take care of their own binding, such as COM IDispatch objects, real dynamic objects such as Ruby or Python ones, or some .NET object that implements the IDynamicObject interface. If it is any of these, then the DLR calls off to the IDO and asks it to bind the action.

Note that the result of invoking the IDO to bind is an expression tree that represents the result of the binding.
If it is not an IDO, then the DLR calls into the language binder (in our case, the C# runtime binder) to bind the operation. The C# runtime binder will bind the action, and will return an expression tree representing the result of the bind.
Once step 2 or 3 have happened, the resulting expression tree is merged into the caching mechanism so that any subsequent calls can run against the cache instead of being rebound.

Jim gives a great description of points 1, 2, and 4, which deal with the DLR specifics, so I'm going to elaborate on what happens in step 3.

The C# runtime binder

The C# runtime binder uses Reflection to populate its internal symbol table to determine what to bind to. Each of the C# specific actions encodes the type of the binding, along with extra information that allows us to determine how to bind the action.

For example, if the argument is known at compile time to have a static type, then that type will be marked in the C# action, and will be used as the type of the argument during runtime binding. If it is known at compile time to be typed dynamic (ie it is a variable of type dynamic, or is an expression that returns dynamic), then the runtime binder will use reflection to determine its runtime type and use that type as the type of the argument.

The runtime binder populates its symbol table as needed. For instance, in our example, we were calling the method Foo. The runtime binder will load all members named Foo on the type of the receiver into the symbol table.

It then populates the necessary conversions for each of the argument types. Since we may need to coerce the arguments to types that match the method calls (using user-defined conversions as necessary), the binder loads those conversions into the symbol table as well.

It then performs overload resolution exactly like the static compiler does. That means that we get the exact same semantics as the static compiler. It also means that we get the same error semantics and messages - a failed binding at runtime results in an exception being thrown, which encapsulates the error message that you would have gotten at compile time.

It then takes the result of overload resolution and generates an expression tree that represents the result, and returns that back to the DLR.

A summary

So that's a brief summary of what the dynamic pipeline looks like. Of course, I've glossed over a lot of the details, but I'll be covering those details in my future posts. Until next time, some questions to ponder:

What happens when the receiver is known statically but the arguments are dynamic? What happens if the methods we're trying to bind against are private? What about operators - how does resolution work on them?

These, and more, I'll aim to address in my subsequent posts.

As always, happy coding!