Re: macros attached to methods

One more think,which come at mind: optimizations performed at compile
time and / or partial evaluation.
This feature gives extremly convenient way to intercept some set of
input kind and emit different implementation for them. A kind of "code
structure overloading". Like List.Map could expand to simple foreach
loop if it is given a simple lambda expression.

Though in general this would again require having the original parsed
tree nodes, as they were before typing.

On 5/4/06, Michal Moskal <michal.moskal@xxxxxxxxx> wrote:
> Hi,
>
> we have an issue report about implementing macros attached to
> particular methods. They should be run, when a given method is
> selected in overload resolution. The original rationale was to allow
> implementing extension methods with this. However we now have
> extension methods anyway.
>
> I'm not sure how such feature would work and when would it be useful?
>
> One use I can think of is implementing .Keys or .Range property in
> array (and possibly other types), that could be used in foreach
> iterations, it would return $[0 .. a.Length - 1]. So the use would be:
>
> foreach (i in a.Keys)
>   a[i] = a[i] * 2;
>
> Unfortunately this won't gonna fly -- the macro would be expanded too
> late for @foreach macro to realize the collection iterated is a range,
> and therefore a specialized code should be used. Maybe if we could use
> some more complicated constraints to delay parts of macro execution,
> but this doesn't seem simple.
>
> Anyway it seems worthwhile to implement such a keys or range macro in
> N.Collections.
>
> Any other ideas when macros attached to methods would be useful? Anyone?
>
> --
>    Michał
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en


--
Kamil Skalski
http://nazgul.omega.pl