[nem-en] declarative multi-staging (runtime specialization not
compile-time)
Michal Moskal
michal.moskal at gmail.com
Sun Aug 6 05:40:44 CEST 2006
On 8/5/06, Korcan Hussein <korcan_h at hotmail.com> wrote:
> Nemerle macros gives us the ability to write partial evaluators at
> compile-time.
>
> NET 2.0 Reflection.Emit.DynamicMethod gives us the abiltiy to write partial
> evaluators at runtime (runtime specialization, which is arguably more
> powerful than compile-time variants). However using DynamicMethod to write
> such code is low-level, i was thinking wouldn't it be a great idea to write
> some syntax macros which gives declarative multi-staging support like
> MetaO'caml/ML, and FreshO'Caml/ML. From what i know it would take adding 3
> operators, quotation of code etc, etc.
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).
> With the ability todo both offline and online partial evalution and mix them
> together elegantly the sky's the limit.
>
> Also wouldn't Reflection.Emit.DynamicMethod be better for implementing
> nemerle functions (or at least lambdas) instead of the current method like
> in IronPython? also could this open up the opportunity for efficent currying
> support? Lastly could this also be a good method for implementing
> multimethods & predicate dispatching.
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?
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).
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).
--
Michał
More information about the devel-en
mailing list