using a function as a custom reduction

[mppf]

GitHub user @vHelenv ran into an internal error when trying to create a custom reduction (issue #12494). What they wrote is this:

proc func(const x: int, const y: int) {
  return x + y;
}
var A = [1,2,3];
var sum = func reduce(A);
writeln(sum);

This gives this error on master: error: func: can not capture overloaded functions as values

and an internal error on previous releases.

However it seems to me that this pattern is natural and fairly clear. Could we support it?

(And either way, we really need better documentation for custom reductions -- we have issue #8139 for that).

[bradcray]

I suspect we've intentionally not documented custom reductions because the interface has been in such flux. But that's arguably not a great excuse not to at least have a technote on it...

A downside of permitting custom functions for reductions rather than declaring it illegal and pointing the user to the (eventual) documentation is that it doesn't support a parallel implementation of the reduction (so may cause the user to miss an opportunity for parallelism / performance). Is that a good enough reason to disallow it? I'm not sure...

Another problem is that without the official interface, custom functions likely don't say much about what the result of a degenerate reduction is:

var sum = func reduce [i in 1..0]  i;

where the official reduction interface does via its identity method.

[mppf]

A downside of permitting custom functions for reductions rather than declaring it illegal and pointing the user to the (eventual) documentation is that it doesn't support a parallel implementation of the reduction (so may cause the user to miss an opportunity for parallelism / performance). Is that a good enough reason to disallow it? I'm not sure...

Why couldn't func in this case be run in parallel? I'd imagine that the compiler would just plug func in to generate and accumulate.

Another problem is that without the official interface, custom functions likely don't say much about what the result of a degenerate reduction is:

That's a good point, but I wonder if there is some way around it. I can imagine having some arguments to the function for this case - but then is it that different from filling in the interface? Alternatively, maybe only reductions with the normal default value (i.e. 0 for an int) as a reasonable starting point can work this way, and you'd use the full interface for other cases.