Operator overloading and loop fusion
Robert Jacques
sandford at jhu.edu
Wed Nov 4 08:08:43 PST 2009
On Wed, 04 Nov 2009 09:47:28 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> I wanted to discuss operator overloading a little bit. A good starting
> point is Don's proposal
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
>
> which discusses the issues involved and makes one major proposal - that
> of equivalence of operators that gives the compiler freedom to eliminate
> temporaries.
>
> Another trend is moving from many named operators to few templated
> operators that simply pass the name of the operator as a compile-time
> string. (If there's a need for virtual functions, it's trivial to have
> the template dispatch to several virtual functions.)
>
> There's a third, more recent idea. When we were discussing about
> array-wise operations, Walter mentioned that he sees no reason why
>
> a[] = b[] + x * c[] * d[];
>
> should not work on other types than built-in arrays. I think that's a
> great idea.
>
> For built-in arrays, that does today
>
> assert(a.length == b.length);
> assert(a.length == c.length);
> assert(a.length == d.length);
> foreach (__i; a.length) a[__i] = b[__i] + x * c[__i] * d[__i];
>
> The general technique is called loop fusion or at least is related to
> it. Instead of writing several loops that compute parts of the
> expression, the statement only defines a loop that does all operations.
>
> So, Walter's idea is to extend such expressions to general ranges. If
> the right-hand side of an expression involves ranges and scalars, and if
> the left-hand side is a range, then the compiler simply writes the loop
> around the lockstep iteration.
>
> I'm unclear how detection would work, e.g. what if a range wants to
> define "+" itself to do something else than fusion? Should operator
> overloading be banned for ranges? That would be too restrictive because
> sometimes you actually don't want fusion.
>
> If we define this well, we can say that the operator overloading is
> quite complete, without growing the language. Between fusion, ETs, and
> temporary elimination, I think we got most everything covered.
>
>
> Andrei
I like this idea. Intuitively the syntax should also work with ranges of
ranges (or arrays of arrays) efficiently.
More information about the Digitalmars-d
mailing list