Dynamic Language Runtime

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Dynamic Language Runtime
Developed by Microsoft Dynamic Language Runtime Team
Latest release 0.9 / December 10, 2008
Operating system Microsoft Windows
Platform .NET
Type System platform
License Microsoft Public License
Website www.codeplex.com/dlr

The Dynamic Language Runtime (DLR) from Microsoft is an ongoing effort to bring a set of services that run on top of the Common Language Runtime (CLR) and provides language services for several different dynamic languages. These services include:

The DLR will be used to implement dynamic languages like Python and Ruby on the .NET Framework. The DLR services are currently used in the development versions of IronRuby, a .NET implementation of the Ruby language, and the upcoming IronPython 2.0.[1] Microsoft plans to use the DLR for the upcoming Visual Basic .NET 10.0 (VBx) and Managed JScript (ECMAScript 3.0).

By having several dynamic language implementations share a common underlying system, it should be easier to let these implementations interact with one another. For example, it should be possible to use libraries from any dynamic language in any other dynamic language. In addition, the hosting API allows interoperability with statically typed CLI languages like C#.

Contents

[edit] History

Microsoft's Dynamic Language Runtime project was announced by Microsoft at MIX 2007[1]. The DLR code currently lives in the IronPython repository. Microsoft planned to ship a first usable 1.0 version of the DLR at the same time as IronPython 2.0, by the end of 2008 [2].

Microsoft shipped .NET DLR 0.9 beta on the 26 November 2008 [3], and final 0.9 on 10 December 2008.

Additional languages include the upcoming IronScheme, a Scheme implementation [4].

[edit] Architecture

The Dynamic Language Runtime is built on the idea that it is possible to implement language specificities on top of a generic language-agnostic abstract syntax tree, whose nodes correspond to a specific functionality that is common to many dynamic languages.[5] This architecture is backed by the idea that the number of elementary language constructs that would have to be implemented on the generic stack should be inherently limited.[6] The DLR dynamically generates code corresponding to the functionality expressed by these nodes. The compiler for any dynamic language implemented on top of the DLR has to generate DLR abstract trees, and hand it over to the DLR libraries.

The DLR provides dynamically-updated DynamicSite objects that cache the task of binding methods to objects. Since in dynamic languages, the type of an object, as well as the members it contains, can change during a program lifetime, a method invocation must check the method list to see if the invocation is a valid one. DynamicSite objects represent and cache the state of the object and its methods; any update to the object is reflected in the DynamicSite objects as well. DLR routes all method invocations via the DynamicSite objects, which then performs a fast lookup and binding of the method with the actual implementation.[7]

In contrast to other efforts like Da Vinci Machine (which aim to add support for dynamic languages in the core of the Java Virtual Machine, thus planning to add new bytecodes in the JVM instruction set, and new JVM capabilities), the DLR is built on top of the existing Common Language Runtime, the .NET Framework virtual machine[8].

[edit] See also

[edit] References

  1. ^ a b Hugunin, Jim. "A Dynamic Language Runtime (DLR)". http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx. Retrieved on 2007-06-21. "For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community." 
  2. ^ Viehland, Dino (2008-01-15). "Roadmap for IronPython 2.0". http://lists.ironpython.com/pipermail/users-ironpython.com/2008-January/006235.html. Retrieved on 2008-02-09. "We don't really have a document like this but the general goal is to ship IronPython 2.0 by the end of the year. For the DLR its self the plan is to ship a v1.0 around the same time as IronPython 2.0." 
  3. ^ http://www.codeplex.com/dlr
  4. ^ http://www.codeplex.com/IronScheme
  5. ^ Hugunin, Jim (2007-05-15). "DLR Trees (Part 1)". http://blogs.msdn.com/hugunin/archive/2007/05/15/dlr-trees-part-1.aspx. Retrieved on 2008-02-23. "The key implementation trick in the DLR is using these kinds of trees to pass code around as data and to keep code in an easily analyzable and mutable form as long as possible." 
  6. ^ Nutter, Charles (2008-01-28). "Lang.NET 2008: Day 1 Thoughts". http://headius.blogspot.com/2008/01/langnet-2008-day-1-thoughts.html. Retrieved on 2008-02-23. "The idea is that there's a quickly-flattening asymptotic curve to the number of expression tree nodes required to implement each new language. Whether that's the case is yet to be seen." 
  7. ^ Bill Chiles. "CLR Inside Out: IronPython and the Dynamic Language Runtime". MSDN Magazine. http://msdn2.microsoft.com/en-us/magazine/cc163344.aspx. Retrieved on 2007-08-10. 
  8. ^ Rose, John (2008-02-02). "Bravo for the dynamic runtime!". http://blogs.sun.com/jrose/entry/bravo_for_the_dynamic_runtime. Retrieved on 2008-02-23. "The differences between the CLR and JVM extensions are interesting to note. They work completely above the level of the CLR without significantly enhancing it, while we are developing the JVM and libraries at the same time." 
Personal tools