Operator/concept interoperability

[TheFlyingFiddle via Digitalmars-d]

On Tuesday, 3 June 2014 at 19:55:39 UTC, Mason McGill wrote:
> I have a numerical/multimedia library that defines the concept 
> of an n-dimensional function sampled on a grid, and operations 
> on such grids. `InputGrid`s (analogous to `InputRange`s) can be 
> dense or sparse multidimensional arrays, as well the results of 
> lazy operations on other grids and/or functions 
> (map/reduce/zip/broadcast/repeat/sample/etc.).
>
> UFCS has been extremely beneficial to my API, enabling things 
> like this:
>
>   DenseGrid!(float, 2) x = zeros(5, 5);
>   auto y = x.map!exp.reduce!max;
>
> without actually defining `map` inside `DenseGrid` or `reduce` 
> inside `MapResult`. `map` and `reduce` are defined once, at 
> module scope, and work with any `InputGrid`.
>
> As this is numerical code, it would be great to be able to do 
> this with operators, as is possible in C++, Julia, and F#:
>
>   auto opUnary(string op, Grid)(Grid g) if (isInputGrid!Grid)
>     { /* Enable unary operations for *any* `InputGrid`. */ }
>
>   DenseGrid!(float, 2) x = zeros(5, 5);
>   auto y = -x;
>
> This is currently not supported, which means users of my 
> library get functions like `map` and `reduce` that work "out of 
> the box" for any grids they define, but they need to do extra 
> work to use "convenient" operator syntax for NumPy-style 
> elementwise operations.
>
> Based on my limited knowledge of DMD internals, I take it this 
> behavior is the result of an intentional design decision rather 
> than a forced technical one. Can anyone explain the reasoning 
> behind it?
>
> Also, does anyone else have an opinion for/against allowing the 
> definition of operators that operate on concepts?
>
> Thanks for your time,
> -MM

> Based on my limited knowledge of DMD internals, I take it this 
> behavior is the result of an intentional design decision rather 
> than a forced technical one. Can anyone explain the reasoning 
> behind it?

Well one reason for this is that unlike methods it is hard to
resolve ambiguity between diffrent operator overloads that have
been defined in diffrent modules.

Example: 2D-vectors
//vector.d
struct Vector
{
     float x, y;
}

//cartesian.d
Vector opBinary(string op : "+")(ref Vector lhs, ref Vector rhs)
{
    //Code for adding two cartesian vectors.
}

//polar.d
Vector opBinary(string op : "+")(ref Vector lhs, ref Vector rhs)
{
     //Code for adding two polar vectors.
}

//main.d
import polar, vector;
void main()
{
     auto a = Vector(2, 5);
     auto b = Vector(4, 10);

     auto c = a + b; //What overload should we pick here?

     //This ambiguity could potentially be resolved like this:
     auto d = polar.opBinary!"+"(a, b);
     //But... This defeats the whole purpose of operators.
}


Side note:

You can achieve what you want to do with template mixins.

Example:

//Something more meaningful here.
enum isInputGrid(T) = true;

mixin template InputGridOperators()
{

    static if(isInputGrid!(typeof(this)))
    auto opUnary(string s)()
    {
       //Unary implementation
    }

    static if(isInputGrid!(typeof(this)))
    auto opBinary(string s, T)(ref T rhs) if(isInputGrid!(T))
    {

    }

    //etc.
}

struct DenseGrid(T, size_t N)
{
     mixin InputGridOperators!();
     //Implemtation of dense grid
}

While this implementation is not as clean as global operator
overloading it works today and it makes it very simple to add
operators to new types of grids.