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