Today was a bonding day for those of us that attended the Compiler Lab, after the morning session and the lightning talks were over most of us stayed around and talk until the end of the day.
In the afternoon, while some of us were busy schmoozing and debating important topics like what was better: Jon Stewart or the Colbert report and lamenting the results of the French elections some other people were actually busy hacking in the afternoon.
Apparently some folks that are working on a ColdFussion compiler got their Cold Fusion compiler using the DLR. Rodrigo and JB were also quite busy hacking in the afternoon.
Good news for Boo users: after I posted my message yesterday about readline-like functionality Cédric Vivier pointed out that he had just implemented the readline capabilities in Booish. You can see the details here.
The morning sessions focused on how to host DLR-bound languages into an application and the various services offered by the DLR infrastructure.
A question that came up is whether it is necessary to support more than one hosting "context" in a single application. Where global variables and types would be shared across multiple scripting instances.
Although today the DLR does not support more than one context, I believe that it should support independent contexts. A case was made for Processes and AppDomains already existing and that adding a scripting contexts was not necessary but if there were interesting scenarios for this setup they could look into it.
In my opinion, AppDomains are too heavy of a separation barrier in an application. They are hard to setup properly and depending on them requires an entire application to be restructured around this new boundary. In the particular case of Boo, multiple hosting environments can exist in a single application and I think this is a good thing.
The best use can I can think of for the need to have multiple hosting contexts would be if the DLR is hosted in two independent libraries A and B developed by two independent groups and then having both of those libraries consumed by a third party. The developers of A and B should not have to talk to each other.
Another example: I could imagine a setup where I want a scripting context for extending the internals of my application and on the same process, I would like to have a second scripting context that does not have access to the internals of my application, but instead is used by the user to write/prototype whatever it is that my application hosts.
An accounting application that is heavily scripted internally would use one hosting context for its internal scripting facilities: forms, rendering, accounting and another scripting context would be used for doing report scripting: a much more limited environment that would not get access to all the application internals and types and globals, but only those that make sense for the reporting infrastructure.
Anyways my vote: yes, we need multiple hosts per AppDomain.
There was a demo of some scripting editor during the talk that hosted the DLR itself but Google does not turn up anything useful about it (Nessie), it looked cute.
In the second part of the sessions they showed some examples of what kind of code IronPython, IronRuby and the Javascript compilers generate.
The DLR in particular provides support for capturing the environment (to create proper lambda functions). A key point during the presentations was that providing as much information the DLR as possible allowed it to optimize the code.
Rodrigo -the author of Boo- pointed out during one of the breaks that he did like the optimizations that scripting developers were getting for free.
In a similar spirit to what the DLR team did by refactoring IronPython into the DLR and then growing languages out of it, Rodrigo and JB talked about a similar project.
Based on the Boo codebase and their joint work on Cecil while they both worked at db4objects they created Milo (which is available here: http://code.google.com/p/milo/.
Milo's goal is to simplify the development of a compiler that targets the .NET framework
Their new DLR-based Javascript compiler (that implements the current ECMA spec) was written by two developers in four months. Nandan Prabhu was at the conference and he explained that if they were to rewrite it today it would probably take three months for a programmer to implement as such a person would not have to keep up with the daily changes in the DLR.
The current sizes for the runtime and the compiler are:
-rw-r--r-- 1 root root 114688 2007-05-02 04:07 Microsoft.JScript.Compiler.dll -rw-r--r-- 1 root root 299008 2007-05-02 04:07 Microsoft.JScript.Runtime.dll
Extrapolating that from our compiler source code it seems that the code is roughly 35,000 lines of code for both the compiler and the runtime. And the compiler is only one fourth of that, so something in the 9,000 line range.
Another interesting detail: the new Javascript compiler is written in Visual Basic.NET.
The day ended up with a fascinating discussion in the kitchen with the Jims (Miller and Hugunin) about languages, big integer support, scheme, python, academia and practice and tons of anecdotes of the early days of the CLR and Jim's days at MIT.
Posted on 23 May 2007