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

[Michal Moskal]

On 8/6/06, Snaury <snaury at gmail.com> wrote:
> 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.

Consider:

def o = create_object()
foreach (i in [1 .. 10000])
  late { o.Foo ("foo", i) }

As the type of the object doesn't change, we could reuse the same
method. And I think, if we could get away with using reflection to
invoke the dynamic method, it would be faster.

Granted, it does seem really hard to implement, and is probably not worth it...

-- 
   Michał