I am glad to see that with 1.29 some simple functions can be passed as arguments to other functions/procedures in a more "natural" way, similar to C. However, the compiler chokes with "open" array arguments (arrays whose actual shape and size can vary) as in the following 3-liner:
type T0 = proc(const in x: real, const in y: real): real;
type T1 = proc(const in x:real, const ref y: [] real);
type T2 = proc(const in x:real, const in y: real): [] real ;
The compiler first complains about T2 and the trouble is the [ ] real; return type. If you comment this line, it complains about T1 where apparently the trouble now is the y: [ ] real part...
I know there are workarounds, like wrapping a function inside a record, but I wish some day Chapel's compiler will be able to digest T1 and T2 
Hi Nelson —
That's an interesting question... How constrained are the arrays for which you'd like to write these patterns? For example, are they rectangular and dense rather than sparse or associative? Are they of a fixed dimension (e.g., 1D) rather than arbtirary dimensions? Are they local rather than distributed arrays? These are all factors that make a formal type like : [] real very generic in Chapel, and I suspect that the more precisely we can dial these questions in for a given use-case, the more easily we'd be able to support first-class functions for them in the near-term using something like a C function pointer (since it would encode all that type information into the signature). Without that, something much more heroic would need to happen, I believe...
-Brad
Hi Brad: I see! Right now, local 1-D arrays would fit all applications that I can think of.
Cheers,
Nelson
1 Like