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

[Snaury]

On 8/6/06, Korcan Hussein <korcan_h at hotmail.com> wrote:
> >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.

I don't see how late macro could benefit from DynamicMethod. To emit
dynamic method for late binding at runtime you would have to know the
exact type of object and the exact type of method you want to call
(something which is not even possible for Com objects I think), so
basically you will have to do all the work DefaultBinder does, plus
generate this DynamicMethod for a single call, which might get called
only once. So many work for gaining nothing? Especially if we consider
that at least ms runtime already does a bit of caching for
InvokeMember without parameter reordering.

> 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..."

Why creating DynamicMethod at runtime when we already know all the
necessary information at compile time? Like in this example:

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

We already know all of the types and code for this lambda is perfectly
static, so actual foo() becomes as simple as a class instantiation.
What is DynamicMethod here for?

> 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.

Hmm... either you or me misunderstand what IronPython does. What I
think IronPython does is when it sees a function declaration (def
foo(...): ...) it parses and compiles its body into DynamicMethod so
that it gets jitted and executes as fast as native code, and then it
is used as a delegate. But for late-binding, how so?