www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Operator overloading and loop fusion

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Nov 04 2009
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 04 Nov 2009 09:47:28 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail 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.
Nov 04 2009
prev sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu 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
 


Just read it and I hate it.

Nobody is smart enough to think of all the possible uses for operator
overloading and make a decision as to whether they are valid or worth while.

D's fucktarded ('scuse me, but it really sucks) operator overloading is
the *one* and only respect where C++ still rules D.

Just because you (for certain values of you) deal with numbers doesn't
make the relationship between <, > >= etc cast in stone and semi quoting
an early paper by 'Bjarne Stroustrup' doesn't give any credence to the
argument; he was wrong then and so is Don now.

(and btw, does Bjarne still feel operator abuse is a bad idea?)

boost::spirit and boost::Xpressive are 2 for instances, which make
incredibly good use of operator abuse to achieve seriously useful
functionality.

I think the main problem is calling these functions 'operators'.

Rather step back and call them 'infix function notation'.
Stop imagining the objects they operate on as numbers and then you can
do some really funky things.

D needs more operators not less and operators defined globally;
so I can finish porting boost::spirit properly.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFK82sMT9LetA9XoXwRAjXxAJ40jHoQqal1l6/vpV3lNlEJwT+AKgCgtOWG
QWQpTFfEH80eqxm5TpvU0xU=
=/62J
-----END PGP SIGNATURE-----
Nov 05 2009
parent Travis Boucher <boucher.travis gmail.com> writes:
div0 wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Andrei Alexandrescu 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


 
 Just read it and I hate it.
 
 Nobody is smart enough to think of all the possible uses for operator
 overloading and make a decision as to whether they are valid or worth while.
 
 D's fucktarded ('scuse me, but it really sucks) operator overloading is
 the *one* and only respect where C++ still rules D.
 
 Just because you (for certain values of you) deal with numbers doesn't
 make the relationship between <, > >= etc cast in stone and semi quoting
 an early paper by 'Bjarne Stroustrup' doesn't give any credence to the
 argument; he was wrong then and so is Don now.
 
 (and btw, does Bjarne still feel operator abuse is a bad idea?)
 
 boost::spirit and boost::Xpressive are 2 for instances, which make
 incredibly good use of operator abuse to achieve seriously useful
 functionality.
 
 I think the main problem is calling these functions 'operators'.
 
 Rather step back and call them 'infix function notation'.
 Stop imagining the objects they operate on as numbers and then you can
 do some really funky things.
 
 D needs more operators not less and operators defined globally;
 so I can finish porting boost::spirit properly.
 
 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iD8DBQFK82sMT9LetA9XoXwRAjXxAJ40jHoQqal1l6/vpV3lNlEJwT+AKgCgtOWG
 QWQpTFfEH80eqxm5TpvU0xU=
 =/62J
 -----END PGP SIGNATURE-----


One of D's strongest points is it's discouragement of 'funky things'. 
Operators like compare are designed for things like sorting, and doing 
funky things with them (for example, modifying the internal state of an 
object) should be something that is discouraged.

Keep operators logical, and use other language features such as 
delegates if you want to do 'funky things'.
Nov 05 2009