Chapel: make promotion and iterators preserve shape/domain

[vasslitvinov]

We would like promotion to produce the result of the same shape as the expression being promoted. For example, A*5 , where A is an array, should produce an array of the same domain as A.

When multiple expressions are promoted, the shape should be determined by the first expression. For example, A+B , where A and B are arrays, should produce an array of the same domain as A. This corresponds to the "leader" in a zippered forall loop.

The case that needs design work is when the "leader" is an iterator: #11524.

[tmacd9]

What is the domain of C below?

config const f1 = true;
config const f2 = false;
var A1: [0..2, 0..2] int;
var A2: [1..3, 1..3] int;
var B1: [2..4, 2..4] int;
var B2: [3..5, 3..5] int;

var C = (if f1 then A1 else A2)  + (if f2 then B1 else B2);
writeln(C);

[bradcray]

What is the domain of C below?

In the past, we've proposed that for things that are zipped together (the two conditional expressions in this case), the leader's domain would be taken. So if f1 was true, it would be A1.domain; if false, A2.domain.

[ben-albrecht]

@vasslitvinov - should this be closed?

[vasslitvinov]

@ben-albrecht the last paragraph is not implemented, and we do not have a plan how to do it. This prevents me from closing this.

[bradcray]

I'm having trouble parsing the last paragraph. What's a code example that would illustrate it?

[bradcray]

(or future if one already exists)

[vasslitvinov]

@bradcray I just updated the issue text, except for the first two paragraphs. How much sense is it making now?

[bradcray]

More sense (though I still think a code example would make it particularly concrete). That said, I'd probably fork the "I want to be able to write an iterator that generates an expression of a specific shape" into its own issue. In my mind, this issue has historically been about shape preservation for loop expressions and promoted calls and doesn't need to try and capture every possible case related to shape preservation. The range case could also be split off into its own issue as well (if it hasn't been already). In any case, I worry a bit about this issue bogging down / trying to say too much.

[vasslitvinov]

The iterator case is now #11524. The rest of this issue has been implemented - closing it.