Chapel: allow promotion when looking for leader/follower with chpl__promotionType() ?

[vasslitvinov]

Consider this class:

class ConcreteClass {
  var base : 2*int;
  proc init(x : int) {  base = (x, -x);  }
  proc chpl__promotionType() type { return base.type; }
  iter these() { ... yield whatever ... }
}

Does it support parallel iteration, i.e. leader/follower?

• While there is no such iterator in ConcreteClass, the compiler can promote a ConcreteClass to 2*int.

• That is a homogenous tuple. It DOES support leader/follower.

• Therefore the compiler decides that the leader iterator for ConcreteClass is the result of promoting _tuple.these(iterTag.leader).

How sensible is this conclusion?

How sensible would it be to conclude that ConcreteClass does NOT support parallel iteration?

Is this related to chpl__promotionType() and/or to #5114 ?

If we accept the promoted tuple leader for ConcreteClass's leader, how does the promotion from a ConcreteClass instance happen when leading?

---

The context for this question is:

• test/classes/initializers/promotion/initPromotion.chpl

• The compiler is resolving 1+cc, where cc:ConcreteClass.

• First, the compiler builds the serial iterator for this promotion. Something like for idx in cc.these() do yield 1+idx;.

• Then the compiler inquires whether to build the corresponding leader/follower iterators. Just in case that 1+cc is used in a forall loop or expression.

• For that, the compiler tries to resolve the call cc.these(iterKind.leader).

• As shown above, it promotes cc to 2*int and succeeds.

See also #11829.

[mppf]

I've mentioned this before but I think the compiler should resolve serial/standalone/leader/follower iterators at once in an all-or-nothing way. I think that it shouldn't be possible to get the serial iterator from one place and the leader/follower from another. I think that the tag business is just a workaround for some language design we havn't completed yet that will make it more obvious that these are a group. So, I'd go with

conclude that ConcreteClass does NOT support parallel iteration

[bradcray]

As indicated in issue #5114, I think we should be getting rid of chpl__promotionType() and relying on the presence/absence of these() iterators as an indication for when promotion should take place.

In any case, I don't think it's reasonable to conclude that ConcreteClass supports parallel iteration.

[vasslitvinov]

See also: #11879