YAAS 2 (Another Yet Another Awesome Selection)

Another blog entry accreted from only the finest selection of IronPython related blog postings from the last few weeks:
This entry is notable because Dino Viehland (core IronPython developer) has finally written another blog post! This post is on writing DLR binders, a core part of creating dynamic languages that use the Dynamic Language Runtime. DLR binders define the semantics of your language, and Dino explains them along with some C# example code implementing integer addition:
There’s a few key pieces you need to understand here. First you’re returning an expression tree back to the DLR to tell the DLR what to do. The DLR will compile this expression tree and run it. You’re also returning a set of restrictions. These will be evaluated by the DLR to see if it can re-use the same code for other objects in the future. You’re unlimited in what you can do with restrictions as they can be arbitrary Expression trees. But here I’m simply restricting based upon the arguments .NET types which is one of the most common restrictions. Both the expression tree and restrictions get packaged up in a DynamicMetaObject which is conveniently the same type of object you receive as your arguments.

Finally there’s the hash identity which is how the DLR knows if it can share rules or not amongst different binders. The base DLR binders override GetHashCode/Equals to hash on the operation, member name, etc depending on the binder type so I just return this here.
A three page article on Developer Fusion about how programming languages on the .NET platform are evolving in .NET 4.0 (which includes C# 4.0 and Visual Basic 10). A big part of this is the introduction of the DLR to the .NET framework to provide dynamic features to both C# and VB.NET.

Perhaps the most exciting new feature in the upcoming .NET 4.0 release is the Dynamic Language Runtime (DLR). In as much as the Common Language Runtime (CLR) provides a common platform for statically typed languages like VB.NET and C#, the Dynamic Language Runtime provides a common platform for dynamically typed languages like JavaScript, Ruby, Python, and even legacy COM components. It represents a major leap forward in language interoperability for the .NET Framework, providing an abstraction of language operations, shared memory space to avoid marshalling data back and forth between processes, a common set of language features like garbage collection, and the plumbing to convert different representations of data from one language to another.

At a high level, you can think of the Dynamic Language Runtime as having three layers:

  • .NET Language Integration
  • DLR Core Components
  • Language Binders

The first layer, .NET Language Integration, simply represents the need for .NET languages to have a notion of what the DLR is and how to use it. For the most part, you won't even notice this aspect of the DLR because most of the .NET languages had a natural integration point. IronRuby and IronPython are both dynamically typed languages, so the DLR fit right in. VB.NET has always supported the notion of late binding on the Object type, so the DLR incorporated nicely into late binding resolution. C#, however, has no notion of late binding and needed an additional static type for dynamic language support. It's called the dynamic type, and we'll talk about it in more detail a bit later.

The second layer is the Dynamic Language Runtime itself, which consists of three core components: Expression Trees, Dynamic Dispatch, and Call Site Caching. An Expression Tree is a representation of code in the form of a tree, which helps abstract languages into a consistent format on which the DLR can operate. Once dynamic code is in a tree representation, the DLR can look at the tree and generate CLR code from that tree for actual execution. Parsing dynamic code into an expression tree and then building the CLR is an expensive operation, so the DLR employs a performance technique known as Call Site Caching to avoid having to "recompile" the dynamic code each time it's called. Dynamic Dispatch ensures that appropriate Language Binders are used for dynamic invocations.

Language Binders, which make up the third layer, are language-specific implementations of certain operations the Dynamic Language Runtime needs to understand about each language that wishes to participate in the DLR.

Of course, the DLR is far more detailed than this brief overview can provide. For more information on all of its intricacies, please watch Jim Hugunin's PDC talk on Dynamic Languages in .NET

The article also covers the new language features in C# 4 and VB.NET 10, the focus on concurrent programming and F# (a functional programming language for .NET based on Ocaml) becoming a 'first class' .NET programming language.
Boo is another .NET programming language: a Python inspired statically typed language with support for macros and duck typing. There are a whole host of new features "huge improvements all over the board" to quote the release notes, including new macros, pattern matching and generic extension methods. It looks like Boo can also now be used for programming Silverlight!
Whilst we're on the subject of Python inspired .NET languages, there is another Cobra update. Just a few improvements this time, but the language seems to be maturing nicely. It has survived quite a while - and for any new programming language surviving beyond a few months is a major achievement. Cobra is also a Python inspired .NET programming language, with static and dynamic binding and first class support for unit tests and contracts. Like Boo it runs on both .NET and Mono.
In a blog simply titled 'Code' there is some example IronPython code! It is an example of using the MySQL database (System.Data and MySql.Data.MySqlClient). The example reads data from a database and writes it to the console (although why use Console.WriteLine instead of print I have no idea).
In the last selection we read Darren Hawley's note to self number 6. Note 7 is als on IronPython - and this one is on naming Python modules and more exultation of SciTE as an IronPython editor.

Comments

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

Should Python Projects Support IronPython and Jython?

Further Adventures of the Debugger