Wednesday, 9 December 2009

Mono and C# 4.0

I am very happy to announce that the Mono C# compiler is now C# 4.0 feature complete.

Covariance and contravariance

The initial work was done by Scott Peterson and then I take taken over and continue developing and advancing the feature. The implementation was rather straightforward especially because C# 4.0 only supports covariance and contravariance on delegates and interfaces. The trickiest and most challenging part was to upgrade type inference to deal with variant type arguments and to provide a meaningful error reporting.

Optional parameters

Optional parameters as of C# 4.0 are limited to the CLR 2.0 functionality which in plain speak essentially means that only constant expressions are supported. The feature adds what VB supported for quite some time but does not add anything new although the integration with existing features like nullable types has been done.

Named arguments

This is probably the trickiest new features of C# 4.0. It may look like simple add-on but by its nature it relates to the most complicated part of C# language. There were several areas where we had to be careful such us overload mechanism, side effects execution, virtual methods, and partial method integration. Most importantly to ensure left to right evaluation any non-constant expression is always copied before next argument is evaluated. This could have a small performance penalty but it was necessary to make our implementation robust.

Dynamic binding

I am not going to explain what dynamic binding is as many people did it before and it can be easily found on the Internet. Instead I am going to focus on how we have implemented it and where it fits to Mono stack.

Dynamic binding is fully integrated into the C# language and any statically bound expression can also be bound dynamically using the new “dynamic” type. This may sound easy but it has been a lot of work even if we had sources of Dynamic Language Runtime (DLR) available when started it and Mono C# compiler has been written in C# from the begging. To better illustrate the concept from compiler perspective here is the structure we ended up with.




Static compilation is on the left side, we can call it a phase I, where everything goes as usual until keyword “dynamic” is resolved in C# source file. At this point all what can be done is to pack the expression and its context into what is usually called payload and redirect the resolver to this payload which gets later emitted instead of evaluated expression. At this point I'd like to point out that even if C# compiler defers the actual resolution to runtime it still tries to do as many static checks as possible to reduce number of possible errors from dynamic binder.

Now we have successfully compiled our application and we can run it. Any dynamic binding code can only run on Mono trunk or .NET 4.0 as it requires a new dynamic binder infrastructure which had not been available in versions before. What you can see on the right side of the image is the magic box called DLR which is the dynamic infrastructure handling all dynamic operations on top of CLR and that's where we come back to life with our dynamic C# binder. We defer all dynamic handling to DLR and only register our payload with DLR call-site so we can be called when DLR decides there is a need for dynamic resolution. When such situations happens C# runtime binder loads the payload created in the phase I and calls back the Mono C# compiler resolver with the restored expression and the context mimicking the static compilation. This has huge benefits for Mono as we have a single code base for both static and dynamic binder. It also has a positive impact on dynamic binder as errors reported during runtime execution will be exactly same as with static binder.

It's also worth mentioning that DLR works strictly with objects only which means any value types dynamic operation will require numerous boxing and unboxing operations and that will slow it down the operation significantly and should be therefore considered before using with dynamic binder.

What about other C# 4.0 features?

There is not really that much left. We have decided not to implement true COM interoperability features for now as we see a minimal usage for them in Mono stack however we may reconsider it at a later stage.

20 comments:

Sandy said...

Great work! This is excellent news, you guys are my heroes. :-)

jpobst said...

Congrats Marek!

This is great work!

Anonymous said...

I am downloading Mono from SVN to try this out!

Casper Bang said...

Awesome! What's next? C# 5.0 and binding operators? [http://www.kodefuguru.com/post/2009/12/03/Binding-Operators-for-CSharp-5.aspx] :)

J.P. Park said...

Great work!! Now, I can move to 4.0 :-)

Dino Viehland said...

On "works strictly with objects" this isn't entirely true. If you do:

dynamic x = ...;
x.Foo(DateTime.Now);
or
x.Foo(42);

the call site is strongly typed to receiving a DateTime or int object and that will be passed through to the receiver unboxed. It is true that return values will always be boxed though because you never know what the return type will be.

Did you make your payload and payload creation functions match csc? Just curious if this ends up working cross implementation.

(BTW you say both static and dynamic compilation are on the right side).

Carlos Alberto Cortez said...

Congrats, my C# compiler mentor!

drhowarddrfine said...

Meh. You Windows people ought to learn proper *nix tools instead of your helper programs cause you can't figure out how *nix works. Give me proper *nix tools instead of Microsoft crutches any day.

Marek Safar said...

@Dino Viehland

Our C# binder can handle csc produced payload and vice versa we produce only payload which can be handled by Microsoft version of C# binder.

Jan-Eric said...

Nice!

Did System.Tuple make it into the release ?

JE

koubel@seznam.cz said...

Nice work, just one question, what's about code contracts? Is it C# or .NET feature and will be in some mono release?

Anonymous said...

well done!
timo

Marek Safar said...

@JE: Mono includes Tuples since version 2.6.

@koubel@seznam.cz: Code contract are BCL (base class library) feature and we haven't implemented them yet.

FEWT said...

This is great, and just what we needed for Linux RAD.

Thanks for the efforts on Mono!

simi said...

hi,

First of all. Thanks very much for your useful post.

I just came across your blog and wanted to drop you a note telling you how impressed I

was with the information you have posted here.

Please let me introduce you some info related to this post and I hope that it is useful

for .Net community.

There is a good C# resource site, Have alook

http://www.csharptalk.com

simis

Quran said...

Thanks a lot for such a good information in this article.

Term paper said...
This comment has been removed by a blog administrator.
custom writing service said...

Great job! I will download Mono C# compiler to try it out. I think I saw the information about its release in some blog of a custom writing service and so many positive feedbacks about it! Thank you lots!

Hamza said...

Nice blog..

hamza@samruz.com
http://www.jobspert.com

Translation Services said...
This comment has been removed by a blog administrator.