[nem-en] RE: declarative multi-staging (runtime specialization not compile-time)

[Korcan Hussein]

>It seems more or less possible by using the compiler as a library. You
>can take a look at the nemish sources (nemerle/tools/nemerlish) for an
>example. It generates an assembly instead of a DynamicMethod though.
>This seems hard to change, as Nemerle methods may produce classes
>(lambda expressions, closures and the like).

Maybe a combined approach would be best.

>You mean if we have:

>foo (x:int) : int -> int
>   fun (y) { x + y }

>then we would invoke DynamicMettor emitter to get a new method for the
>lambda expression?

I' something like that yes, i think there might be some oppunitities here 
and there that might be worth exploring.

Another important thing i forget to mentioned is DynamicMethod can be used 
to implement efficent late-bound invocations, IronPython also uses 
DynamicMethods to implement efficent duck typing. We could also use this in 
the late binding macros that you guys have been working on.

>It's definitely a trade off. The execution is likely to be faster. The
>creation is however likely to be longer. And I guess most of the
>lambda expressions are called once. I also don't know if we can invoke
>such dynamic method without going through delegates or even
>MethodInfo.Invoke (which both use Reflection and are slow).

This is what the docs say:

    "You can use the DynamicMethod class to generate and execute a method at 
run time, without        having to generate a dynamic assembly and a dynamic 
type to contain the method. The executable code created by the just-in-time 
(JIT) compiler is reclaimed when the DynamicMethod object is reclaimed. 
Dynamic methods are the most efficient way to generate and execute small 
amounts of code..."

IronPython use DynamicMethods to implement function as first-class entities 
and late-binding efficently, just some of the reasons that give IronPython 
the edge over other Python imps. Then again due to the dynamism of python 
this might not help with nemerle.

>Anyway the good thing is, that they claim they would garbage collect
>the IL code.

>I would love to see some benchmarks (mesuring creation time, execution
>time and hopefully checking for garbage collection).

These links might interest you:

http://blogs.msdn.com/hugunin/
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20051103CLRJP/manifest.xml
http://blogs.msdn.com/joelpob/archive/2004/04/01/105862.aspx