John Gietzen

Ok, I have put the most recent NuGet versions up on the downloads tab.

@hakanson: We are already using the ECMAScript option, which works well for the most part. It is just this little piece that is different.

We found that in a loop like this... ``` while (true) { var r = new RegExp("..."); } ``` ...that .NET's regex cache was not helping. When we implemented the...

We could optionally just include System in the global namespace, and support the new keyword as-is for non-generics. We could then use a different symbol for type parameters (maybe backticks?)...

@jhugard I don't think that it is a good Idea to "pollute" the import keyword with our own interpretation. If future versions of ECMAScript define it differently than we do,...

I guess that my voite is for the contextual version of the "clr" keyword: valid: `var foo = clr new System.StringBuilder()` also valid: `var clr = true;`

If we are going to use a URL prefix, I would suggest we go with the precedent set down by Microsoft: `clr-namespace:SDKSample;assembly=SDKSampleLibrary` This is for XAML namespaces, but I think...

@slide; it is the same as suggested above, except for the "-namespace" addition...

@fholm: Well, that doesn't let the scripts stand on their own... The hosting application would have to know which assemblies were desired beforehand. Of course, there may be security concerns...

Ah, before we go to far implementing this, I think we should familiarize ourselves with the way that IronPython does types and generic types: http://ironpython.net/documentation/dotnet/dotnet.html