www.digitalmars.com         C & C++   DMDScript  

D - Operator overloads and mixins

reply Hauke Duden <H.NS.Duden gmx.net> writes:
All this talk lately about how operators are overloaded gave me an idea 
that I thought I'd mention. Maybe it is something for a later version of D.

I think that it would be nice to have the ability to overload comparison 
and mathematical operators individually. Right now we have to overload 
sets of them (cmp for <,<=,>,>=,==; opMul for opMul_l and opMul_r, etc). 
This can be a problem when dealing objects that do not follow the rules 
that apply to normal numbers.

I understand the reason why it is this way: Walter wants to avoid 
C++-like bloat of the source (e.g. having to write 8 operators instead 
of one). However, I think this shortcut limits the power of D, so it 
would be nice to have another alternative.

And with the recently discussed mixins there would be one! Operators 
could by default be separate functions, much like in C++. The D standard 
library could then provide a "DefaultOps" mixin that provides 
implementations for these functions that forward the calls to the single 
combined function that we have right now.

Then you could still use cmp instead of defining the 8 operators 
individually - all you'd have to do is write "mixin DefaultOps" in the 
class definition. And if you want to define the operators yourself, just 
leave out the mixin and write your 8 functions!

Hauke
Jan 07 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Hauke Duden wrote:

 I understand the reason why it is this way: Walter wants to avoid 
 C++-like bloat of the source (e.g. having to write 8 operators instead 
 of one). However, I think this shortcut limits the power of D, so it 
 would be nice to have another alternative.


There are 2 decisions behind it which are documented in the manual, if i 
recall it correctly:

- operator overloading should only be used for numeric types. Everything 
else is considered misuse by Walter.
- commutativity of operators may be hardwired into the compiler, to 
enable better optimisations. Like a simple function, which gets a,b,c is 
faster as "return c+b+a" than return "a+b+c". This should be possible to 
optimise away someday. Even for overloaded opeators.

-eye
Jan 07 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ilya Minkov wrote:


 I understand the reason why it is this way: Walter wants to avoid 
 C++-like bloat of the source (e.g. having to write 8 operators instead 
 of one). However, I think this shortcut limits the power of D, so it 
 would be nice to have another alternative.


 
 
 There are 2 decisions behind it which are documented in the manual, if i 
 recall it correctly:
 
 - operator overloading should only be used for numeric types. Everything 
 else is considered misuse by Walter.


True, but there are many different numeric types and lots of them follow 
different rules than normal integers. And for normal numbers you 
probably won't need to overload operators, because they are already 
implemented as simple types!

Or are you saying that the only good use of operator overloading is for 
a bignum package? That's the only thing I can think of where you need to 
wrap something with integer-like properties in objects, instead of using 
the simple integer types.

For example, matrices are used a lot in many graphics-intensive programs 
(games, 3D modelers, etc.), but they follow different rules. 
Unfortunately, you couldn't implement proper matrix-operators in D :(.



 - commutativity of operators may be hardwired into the compiler, to 
 enable better optimisations. Like a simple function, which gets a,b,c is 
 faster as "return c+b+a" than return "a+b+c". This should be possible to 
 optimise away someday. Even for overloaded opeators.


I think such cases would be pretty rare, as in most cases it will be 
difficult for the compiler to decide which version is faster.

And in any case, I would MUCH prefer a less restrictive language than 
saving a few clock cycles. Let's face it, speed isn't everything 
nowadays and D is a high level language. There are lots of things in 
HLLs that technically "waste" clock cycles, but we accept them because 
they make our lives as programmers easier. And IMHO a potential(!) 
optimization possibility for some rare cases just isn't much of a 
justification for imposing such strict rules. There is even a good 
possibility that no D compiler will ever implement this optimization 
because there is so little to gain by it.

Hauke
Jan 07 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Hauke Duden wrote:

 Or are you saying that the only good use of operator overloading is for 
 a bignum package? That's the only thing I can think of where you need to 
 wrap something with integer-like properties in objects, instead of using 
 the simple integer types.


You could do a bignum, a fixpoint, and something like a software-steered 
high-precision floating point. You can also do anything which is a ring. 
There is an infinite number of rings you know. For example, the polynom 
ring. And the modulo prime rings.


 For example, matrices are used a lot in many graphics-intensive programs 
 (games, 3D modelers, etc.), but they follow different rules. 
 Unfortunately, you couldn't implement proper matrix-operators in D :(.


True. But the a.dot(b) notation is not that bad. Here were already 
proposed named and registerable operators like a "dot" b or a dot b or 
even something like that with unicode or other symbols, all of these 
having the same precedence among each other and roughly the same 
precedence as a function call. I even proposed that it be an error to 
rely on precedence in such cases, like lint can flag it on C with rarely 
used operators. Walter promised a syntax extension mechanism by D 2.0, 
and this would give us not only such, but at will also many other gimmicks.


 - commutativity of operators may be hardwired into the compiler, to 
 enable better optimisations. Like a simple function, which gets a,b,c 
 is faster as "return c+b+a" than return "a+b+c". This should be 
 possible to optimise away someday. Even for overloaded opeators.


 
 
 I think such cases would be pretty rare, as in most cases it will be 
 difficult for the compiler to decide which version is faster.


There are approximate clocking tables. This way having 2 code paths, 
even a fairly simple compiler could decide for a shorter one. The 
problem is, complexity grows exponentially with the number of such 
desisions per function, if they can overlap! (If i'm not mistaken)


 And in any case, I would MUCH prefer a less restrictive language than 
 saving a few clock cycles.


This definately makes sense. But then again, there are 2 fields: high 
performace numeric code and "inner loops", and the usual roundabout 
stuff. In inner loops you would usually dispense of all high level stuff 
which could hinder at optimisation. But i would not like to give up on, 
say, fixpoint, which is written exactly for the high performance code. 
On the other hand, direct optimisations on fixpoint are not requiered, 
since it boils down to integer, where the real job is done. Maybe you're 
right after all. But Walter has fairly strong opinions you know. Good 
that he does.

-eye
Jan 07 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ilya Minkov wrote:

 Or are you saying that the only good use of operator overloading is 
 for a bignum package? That's the only thing I can think of where you 
 need to wrap something with integer-like properties in objects, 
 instead of using the simple integer types.


 
 
 You could do a bignum, a fixpoint, and something like a software-steered 
 high-precision floating point. You can also do anything which is a ring. 
 There is an infinite number of rings you know. For example, the polynom 
 ring. And the modulo prime rings.


There is also an infinite number of non-rings ;). I guess my point is 
that if you limit yourselves to rings you sacrifice a lot of the 
usefulness of operator overloading.


 For example, matrices are used a lot in many graphics-intensive 
 programs (games, 3D modelers, etc.), but they follow different rules. 
 Unfortunately, you couldn't implement proper matrix-operators in D :(.


 
 
 True. But the a.dot(b) notation is not that bad.


You're right. But being able to write formulas in code as you do on 
paper can make things more readable. You CAN live without custom 
operators, but sometimes it is just more convenient to have them. For 
example, a lot of physicists do not want to use JAVA simply because 
there are no operator overloads for complex numbers. You have a lot of 
formulas in simulation programs, and being able to enter them in a 
readable way is a big advantage.

But I am repeating myself. This argument already took place a few months 
ago - there's not much sense in doing it all over again.


Hauke
Jan 07 2004