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.

Hosting and the Case for Multiple Hosts

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.

DLR Code Generation Scenarios

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.

Milo: Compiler Infrastructure

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

Cute Anecdotes

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.

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.

Dinner

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.