Can we fix reverse operator overloading (opSub_r et. al.)?

[Lars T. Kyllingstad]

Don wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> Andrei Alexandrescu wrote:
>>>> Walter Bright wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>> This also reminds me that the entire operator overloading feature 
>>>>>> must be thrown away and redesigned.
>>>>>
>>>>> :-(
>>>>
>>>> It's run its course like an old BMW. We need to do new things, and 
>>>> bolting them on what we have won't work.
>>>>
>>>> Andrei
>>>
>>> Indeed, I even think that the concept of operator overloading is wrong.
>>> In C++, operator overloading was just for syntax sugar. That's wrong: 
>>> pretty much everything that you want overloaded operators for, is 
>>> performance-critical. And that implies you need to deal on the level 
>>> of complete expressions, not individual operations.
>>
>>
>> That is true. There is, for instance, a good reason why the basic BLAS 
>> matrix multiplication routine calculates
>>
>>   a A B + b C        (a,b: scalars; A,B,C: matrices)
>>
>> instead of just AB.
>>
>> Would/could one could gain something, performance-wise, by having such 
>> "expression overloading" as a built-in feature of the language itself, 
>> rather than as a library?
>>
>> BLADE has already shown that it is possible to do stuff like this in a 
>> library, but I think it goes without saying that if it was built into 
>> the language the syntax could be made considerably nicer. Compare:
>>
>>   auto m = MatrixOp!("a*A*B + b*C")(aVal, bVal, aMtrx, bMtrx, cMtrx);
>>
>>   auto m = a*A*B + b*C;
>>
>> If D could do this, I think it would become the next FORTRAN. :)
>>
>> -Lars
> 
> Curiously, in the DMD front-end, that's almost what happens with array 
> operations.
> x[] = a*y[] + c*z[];
> gets translated into:
> __somemangledarrayfuncname(x, y, z, a, c);
> 
> and creates:
> 
> __somemangledarrayfuncname(T[] p1, T[] p2, T[] p3, T c1, T c2)
> {
>   for(int p=0; p < p1.length; ++p) {
>     p1[p] = c1*p2[p] + c2*p3[p];
>   }
> }
> 
> And there are many bugs associated with this, since the compiler doesn't 
> distinguish x[] from x properly (where x is a dynamic array); you can 
> get internal compiler errors referring to type mismatches of 'p'. This 
> could, I think, be done better by putting a simple version of BLADE in 
> the compiler runtime.
> 
> A big issue with matrix overloading is, what do you with dot product? 
> It's just as fundamental as '+' or '*', but it doesn't have an operator 
> symbol. Consider that a 1x5 matrix multiplied by a 5x1 matrix is just a 
> dot product of two vectors, and a smart compiler would be able to 
> recognize that.

There are actually three (four) basic types of vector/matrix 
multiplication, and the * operator would more or less be fitting for any 
of them:
   - element-by-element multiplication, which is what * means now
   - dot product
   - matrix multiplication
  (- cross product )

I wish more operators were easily accessible on keyboards. (Hey, I just 
found out that "×" is Shift-AltGr-* on my keboard!) Perhaps the modulus 
operator, %, could be reused for one of them? If you drink a few beers, 
add some goodwill, and perhaps squint a little, it almost looks like a 
cross. ;)


> The other thing that's desperately missing from D is multi-dimensional 
> indexing.

Agreed. But with the aforementioned "expression overloading", one could 
make extremely elegant multidimensional library types...

-Lars