My goal in attending this year’s Lang.NET Symposium was to determine whether the Common Language Infrastructure (CLI) is a viable platform on which the Perl 6 language can be implemented.  During the talks, I took notes in my blog (Monday, Tuesday, Wednesday) and on my wiki (Monday, Tuesday, Wednesday).

Since I’ve not historically been much of a compiler guy, and since I don’t know what type of human power is available to perform such an implementation, I can’t say with any level of assurance whether or not targeting the CLI is feasible by the Perl 6 community. However, based on my limited understanding, it seems like it can be done. There has been a lot of work done by the IronPython and IronRuby teams to make implementing so-called "dynamic" languages (interpreted languages, languages with an eval() mechanism) as painless as possible. Based on conversations with Jim Hugunin, the primary developer of IronPython and one of the core developers of the DLR, I believe that the Perl 6 language would be welcomed with open arms by the CLI and DLR development communities, if interest exists in leveraging these technologies.

Microsoft has published the source to both IronPython and IronRuby, along with the Dynamic Language Runtime (DLR) libraries under the OSI-approved, bsd-style "Ms-PL" license.  The DLR contains implementations of many features common between dynamic languages, and could be leveraged to implementat a Perl 6 runtime on top of the Common Language Infrastructure.

The open issues remaining involve some questions which had been brought up by Larry Wall prior to the conference:

[One] interesting question is how hard it’ll be to at least emulate continuations for purposes of pattern matching and logic programming; and whether that forces Perl 6 to keep its own runloop.

Another interesting question is the extent to which we can make their exception model fail-soft in a way that works well [with] parallel programming.  you don’t want to be unwinding the whole stack merely because one element out of your million element hyperoperation turned out to be undefined….  unwinding the stack should be the last resort, and then only when you already know where you’re unwinding it to.

Another question is on porting to the CLI is whether it can support STM efficiently.

Based on my limited understanding of the subject, it seems that continuations, fail-soft exceptions and STM would need to be implemented as extensions to the CLI by way of the DLR.

According to Larry, “Perl 6 tries to dance right on the edge of requiring continuations without actually doing so, which opens up many opportunities for doing something more efficient than continuations most of the time.” This seems as if it will mesh better with the current DLR users’ world. When speaking with Jim Hugunin, it sounded as if he would prefer to avoid including support for continuations in the DLR. He mentioned that the Ruby spec has removed continuations, which leaves Perl 6 as the only modern language with the feature.

The way I see it, these features can be implemented in a slow-but-existing manner initially. As common use cases emerge, the system can be optimized. I once visited my friend Eric‘s office when he was on the microsoft.com team. On his wall, there was poster with a message similar to this:

1. Make it work
2. Make it work right
3. Make it work fast

I’ve found that if developers get bogged down in the details of the later steps before the earlier steps are complete, productivity takes a real hit, and sometimes stops completely. The other implementations of Perl 6 seem to understand this, and are not waylayed (much) by the fact that their systems are on the dog side of slow.