Promoted expression cannot be passed as array argument

[rahulghangas]

Summary of Problem

As title

Steps to Reproduce

Source Code:

proc foo(a : [] int) {
  writeln(a);
}

var a : [1..10] int = 1;
var b : [1..10] int = 2;
foo(a+b);

results in a compiler error

promotedArrayAsArgument.chpl:7: error: unresolved call 'foo(promoted expression)'
promotedArrayAsArgument.chpl:1: note: this candidate did not match: foo(a: [] int) [207314]
promotedArrayAsArgument.chpl:7: note: because call actual argument #1 with type _ir_chpl_promo1_+
promotedArrayAsArgument.chpl:1: note: is passed to formal 'a: []'
promotedArrayAsArgument.chpl:7: note: unresolved call had id 207360

Configuration Information

• Output of chpl --version: 1.23.0 pre-release (8366399)

CHPL_TARGET_PLATFORM: darwin
CHPL_TARGET_COMPILER: clang
CHPL_TARGET_ARCH: x86_64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: gmp
CHPL_HWLOC: hwloc
CHPL_REGEXP: re2
CHPL_LLVM: llvm *
CHPL_AUX_FILESYS: none

[rahulghangas]

Nvm, duplicate of #14364

[mppf]

I don't think that this is exactly a duplicate of #14364 because I would assume (and correct me if I am wrong) that in filing this you were thinking that one should be able to pass a promoted expression to an array argument; and in that event the compiler would capture the promoted expression into an array. And that it should do this with the code you have presented. In more compiler-developer terms I would say this is a request that the compiler "allow coercions from iterators to arrays with the same element type". (One wrinkle there is - what if the array argument indicated the shape? What if it were 2D? Does the iterator have to have the same shape as the array?)

That is different from #14364 because #14364 proposes some kind of short way of indicating that in the code the iterator should be converted to an array. That is, the user writes a function call, method call, or cast.

[bradcray]

W.r.t. Michael's interpretation of this issue's ask, I feel nervous about the notion of having an iterator expression implicitly get converted to an array primarily because arrays are passed by ref by default and having a ref to a compiler-introduced temporary array storing the result of a+b makes me feel nervous. If foo() explicitly took a by const ref intent then I'd be less hesitant, but still a bit. If it took it by in intent, then I'd have a harder time coming up with a solid reservation given that we support var c: [1..10] int = a + b; (and I think would ultimately like to support var c: [] int = a + b;).

[mppf]

Yes, generally speaking we only allow coercion when passing an argument to in intent (and not for ref or even const ref).

[damianmoz]

I concur with @bradcray. In fact I just tried to pass a promoted expression to a function I wrote with a const in argument which was an array of reals. The compiler complained. It would be nice for that to work, but happy if ref and const ref do not (emphatically so for ref).

That said, if there is a way of casting that promoted expression into an array as @bradcray promotes (ha-ha) as a solution to #14364, then that approach would also solve this problem (I think). And then this coercion issue would go away as far as I am concerned. I think banning coercion of any type and demanding that a program cast the expression is more rigorous in my humble opinion.

I thought that this and #14364 were the same until I realized, as @mppf alluded to, one was casting and the other coercion.

By the way, I cannot find the words "promoted expression" anyway in the documentation as a pair of adjacent words. I had to go to the list to get some help on my problem with was this issue. No internet returned a match either. The only place I did notice the use of that term was in a recent reply to myself on the list from @bradcray but that was about another issue and I did not make the connection.

[bradcray]

I think banning coercion of any type and demanding that a program cast the expression is more rigorous in my humble opinion.

@damianmoz: Just to make sure I'm understanding: You're using "more rigorous" as a positive attribute here, is that right? (i.e., you'd prefer people be forced to add the cast than for a coercion to take place automatically and invisibly?)

[damianmoz]

Yes, "more rigorous" is always a positive attribute.

[mppf]

In the process of resolving some other issues, (PR #16180 and issues #16185 and #16195), I think that I will end up also allowing iterators to be passed to in / const in formals accepting a type that would result from var A = someIteratorExpression. It sounded like this is probably OK but it would be good to know if there are objections to it.

[bradcray]

Sounds good to me!

[damianmoz]

Remind me (again), or point me at, the latest thoughts on how to cast the promoted expression to be an array please?

In particular, consider the scenario where the return statement within some function (returning any array) casts the said expression to be an array, or that return statement returns simply the name of the array within that function. If now, further consider where a call to that function then appears in the parameter list of a totally different function as-is, i.e. without anything (I assume) to cause promotion, as in

totallyDifferentFunction(..., functionReturningArray(....), ....);

Can I then further assume that there is no need for another cast in that parameter list?

Obviously if I multiplied the results of that function result as in

totallyDifferentFunction(..., functionReturningArray(....) * 2.0, ....);

to create a new expression within that parameter list, that upon that newly promoted expression will there need to be done further casting to an array.

Am I assuming too much or have I missed something? Sorry - too many passive tense verbs in those last two paragraphs.

Note that the argument in the parameter list of totallyDifferentFunction that corresponds to that array would have a type of const ref.

[bradcray]

Hi Damian —

As far as I know, we don't currently support casts from promoted expressions or iterator expressions to arrays... but I think we should (or at least, don't know of a reason that we shouldn't). Specifically, given:

var A = [1.0, 2.0, 3.0];

proc foo(X: [] ) {
  writeln("X is: ", X);
}

I'd expect that a user should be able to write things like:

foo((A * 2):A.type);
foo((A * 2):[0..2] real);
foo((A * 2):[A.domain] A.eltType);

or potentially even:

foo((A * 2):[] real);                                                         
foo((A * 2):[]);

yet none of these work today. If you wanted this capability, one way to do it would be to write an explicit function that "does the cast" where one way to write it using only user-facing features, but in a fragile manner, would be the following:

proc toArray(ir) {
  var arr = ir;
  return ir;
}

The reason I say "fragile" is that, as written, this function could take any type, and not all of them would turn into arrays. A way to make this robust, but to lean on features that we haven't yet exposed to users would be to specify the type of the ir argument:

proc toArray(ir: _iteratorRecord) {
  var arr = ir;
  return ir;
}

at which point, it's possible to write:

foo(toArray(A * 2));

But since we've now dipped our toes into features that aren't user-facing, you could also write the cast yourself (which also isn't a user-facing feature yet), as follows:

proc _cast(type t:_array(?), ir: _iteratorRecord) {
  var arr = ir;
  return ir;
}

at which point these versions work:

foo((A * 2):A.type);
foo((A * 2):[0..2] real);
foo((A * 2):[A.domain] A.eltType);

Note that both of these approaches (cast or toArray utility function) have their advantages. The cast permits you to say what indices the array should have, but also makes you talk about those indices (and the array's element type) pretty explicitly. Whereas the toArray function lets you just say "make this thing an array and let's not discuss the details" and you'll get an array back (with default indices). You could also imagine other solutions in which the toArray() routine established a different lower bound or took the lower bound in as an argument or ...

None of this is specific to your case of "applying a promoted operator to a returned array", but I think these features will work fine in that context as well, and that it's just a matter of chaining expressions.

If the cast shown above is as correct and appropriate as I think it is, it may be that we should just drop that into the internal modules and have it be available by default.