Rounding up DLR questions

I thought I'd answer some more questions that have shown up around the web about the DLR. I was out for a short vacation before getting back to the office middle of this week.

1. Is the CoreCLR available for a standalone download?
   
   No. It's designed to be used with Silverlight. Jamie Cansdale has figured out how to extract the assemblies out of the redist and run a console application using it. Why? Because it makes sense to be able to run your unit tests using the target runtime.
2. Is the DLR itself available for standalone download?
   
   Not at this time. Right now you can download it as part of the IronPython 2.0 Alpha release on Codeplex.
3. Will I be able to host the DLR myself in my own .NET applications?
   
   Yes. We have a generic hosting API, and we internally have a number of hosts built using it, including a console host for the desktop CLR, various test harnesses for our test team etc.
4. Does JS support generics?
   
   Not with this release, but it is on the roadmap.
5. Is the DLR just IronPython's libraries pulled out into a reusable form?
   
   At a certain level, this is true (a simple example is the BigInteger type). However, it does go considerably deeper than this. The DLR has a more ambitious goal of unifying the programming model of static languages and dynamic languages in the most efficient way possible. For details on this, see Jim Hugunin's two posts on The One True Object, particularly Part 2.
6. What about languages beyond the four (IronPython, IronRuby, JScript, and VB) that Microsoft is building? Can the DLR actually be used by folks outside the company?
   
   At the time of this writing, it's exactly 11 days since we shipped bits to the world. Peter Fisk is making good progress porting his Smalltalk implementation to the DLR.

Comments

[Jamie Cansdale]

Hi John,

I have another question for you.

Is Microsoft working on adding support for debugging extension methods? I imagine that would required before we can hope to step through any of these dynamic languages.

Thanks, Jamie.

[Mark]

Is there an ETA on the IronRuby alpha?

Also, I'm a bit confused about the IDE support for IronPython. Right now it seems that you have to go through hoops to get VS support with IronPython. Will a 2.0 IronPython release also include a standard VS addin? Am I right in assuming that there will be an addin for IronRuby too?

[Random Reader]

How will DLR ship on the desktop, so that we can use it to provide scripting support in our own apps?

[John Lam]

@Jamie:

Don't know right now. I'll ask around.

@Mark:

We would like to ship something by end of July.

@Random:

You could just bundle the DLR with your app (permissible under MsPL). We haven't decided whether DLR will ship in binary form with CLR V.Next.

[Random Reader]

Thanks, but it sounds like you meant in source form? The problem is that the languages built on the DLR must reference it like any other assembly, right? So they have to already be in binary form and signed by some central authority -- otherwise I have to build, distribute and maintain the DLR and every single language I want to run on top of it along with my app.

What I'm looking for is something like the old Windows Script scenario: included with the system after X point (which you already answered, and IMO this is ideal), and a redistributable installer for older systems.

A lot of us have been wanting real .NET scripting support since v1.0, and so far there's only been the aborted VSA attempt. I'm anxious to see something fill that gap :)

[M. David Peterson]

@Random,

While this obviously doesn't help from the standpoint of non-Silverlight-based apps, with as much power that Silverlight 1.1 provides coupled with the fact that the DLR ships Silverlight 1.1 w/ IronPython baked into the core, this may very well be the right way to go.

From the standpoint of a ClickOnce app which provides access to the entire .NET FCL, you could just as easily create a separate MSI for the DLR and then make that MSI a required dependency for each of your apps. If someone installed one of your apps that required the DLR, installed it, they would then have no need to install it the next time round.

Actually, if not mistaken, if the assemblies were already on your machine via the installation of an existing ClickOnce app, they wouldn't be downloaded and isntalled again as long as they have the same hash, but the MSI might be a better approach as it would allow access to things such as the registry and the GAC, which you couldn't access if it was installed into the shared area of ClickOnce apps.

[shailesh]

A few question about the CoreCLR. (1) Can we use CoreCLR to build and deploy applications? (2) Can we write our own CoreCLR host (i.e. a C++ host which loads CoreCLR and launch a managed application)? (3) If all this is possible, what are the licensing issues involved?