Controlling `dataPar*` settings on a per-loop instead of per-distribution basis about chapel

[benharsh]

That said, I can imagine two interpretations of your statement:

I was thinking more about option 1 because we have a better understanding of that case, but option 2 is indeed attractive in its own way. I think it would be great if we could support first-class privatization in the language that was optionally proactive or lazy.

[bradcray]

As an update to set_granularity.txt not working, I was able to determine that the problem was due to failing to get each locale's privatized version of the BlockArr/Dom class, and with @benharsh's help determined that this was due to the fact that the these() iterators go through the _array.these() wrapper, which takes care of such issues. set_granularity-blc.txt is a rewrite that avoids the locality issues in the OP. I am thinking about what more we could do here to reduce confusion and the chances for non-local accesses to privatized classes.

A slightly more detailed version of this appears in Gitter and the comments that precede it show some of the investigation that led to the conclusion.

[benharsh]

My initial thoughts regarding privatized classes lean towards a compiler-assisted "localize" call when crossing on-statements. This could potentially cause issues in the (rare?) case where a user does not want the local instance.

Something I've occasionally brought up is the notion of on-statements supporting a with clause to help define how variables are brought across locales. With such a feature we could define the default on-intent for privatized classes to be something like local in, and a user could override that behavior with a simple `inorconst in``.

Something a bit less impactful on the language could simply be allowing for a local intent in the "this-intent" space on methods:

proc local MyBlockArr.these(...) { ... }

These approaches rely on the compiler having some understanding of privatized classes, which does not yet exist today.

[bradcray]

My initial thoughts regarding privatized classes lean towards a compiler-assisted "localize" call when crossing on-statements. This could potentially cause issues in the (rare?) case where a user does not want the local instance.

I'm glad to hear you say that because that's where my thoughts have been going this week, to the extent that I think I often believe that we already have this. But I think I'm getting mixed up w.r.t. the work we did on serializing slices (still off by default).

That said, I can imagine two interpretations of your statement:

1. when a privatized class crosses an on-clause, we serialize it by passing its pid across the wire and then deserialize it by converting that pid back into the local class instance (where my head is)
2. we don't proactively privatize classes at their declaration point (like today), but just serialize the classes as they cross on-clauses (which seems attractive, but seems like it could be expensive for things like descriptors that have numLocales-sized arrays)

These approaches rely on the compiler having some understanding of privatized classes, which does not yet exist today.

I think that makes sense though and seems likely in our future—certainly the current approach isn't great and I think users will want/need similar capabilities without wanting to build them themselves. Also relates a bit to the notion of having a more straightforward way of declaring "per-locale" variables (which I think you were playing with a bit recently, and which I think Daniel's work on local static variables is going to make us want as well).