Should `dmapped` be replaced, removed, or stabilized?

[bradcray]

This issue is an offshoot of one particular aspect of https://github.com/chapel-lang/chapel/issues/17908.

The dmapped keyword, like the dmap type have not been particularly popular terms within the language as time has passed. Currently, dmapped is marked as unstable, where the stable way of creating and applying a distribution to a domain is to use factory methods like Block.newDomain({1..n}) or MyBlocDist.newDomain({1..n}).

While using these factory methods are sufficient for creating a distributed domain, I find myself wishing for a dmapped equivalent since, arguably, we could get rid of Chapel's syntax for declaring ranges, (non-distributed) domains, and arrays and simply write range.createRange(1, n) or domain.createDomain(range.createRange(1, n), range.createRange(1, n)) but find benefits in having syntax like 1..n, {1..n, 1..n} or [1..n, 1..n] real appealing rather than expressing everything as a factory method call.

The history of dmapped was that we wanted something that applied equally well to distributions (domain maps targeting multiple locales) or layouts (domain maps targeting a single locale) and so decided to reserve and make up the dmap type and dmapped operator as a way of picking a word that would be special, not likely to conflict with an identifier a user wanted to use, and corresponded to the Chapel concept of a domain map. While those reasons are sound, dmapped as a keyword remains fairly unpopular, leading to its destabilization.

If we were to replace it 1:1 with another word, some options include:

distributed (example usage: {1..n, 1..n} distributed MyDist)

• Con: This approach has the downside of flowing better for distributions than for layouts
• Pro: However, it matches the .distribution query that we recently stabilized (replacing the previous .dist query) where we decided to simply think of layouts as degenerate distributions (or, potentially "distributions of indices/elements to memory")
• Pro: Reads fairly naturally relative to dmapped
• Con: A bit long
• Con: May be an identifier that a user would want to use (e.g., a boolean field or flag indicating whether something is or should be distributed?)

stored (example usage: {1..n, 1..n} stored MyDist)

• Pro: Of a reasonable length for a keyword
• Pro: Seems less likely to conflict with a user identifier (?)
• Pro: More neutral w.r.t. distributions vs. layouts
• Neutral: Potentially applicable in other contexts, though potentially slightly clunky (e.g., atomic int stored [processor|network])
• Con: Less correspondence with .distribution query

implemented (example usage {1..n, 1..n} implemented MyDist)

• Con: Back to a longer keyword
• Pro: Unlikely to conflict with user identifiers
• Pro: Potentially applicable to other contexts (e.g., atomic int implemented [processor|network])
• Con: Less correspondence with .distribution query

move distribution information to type?

In #17908, Vass noted a BHarsh-inspired proposal to move distribution information into the type rather than in the value field. While this is a possibility—and the distribution type is clearly a property of a domain or array—it has the downside of not being applicable in a value context. That is, there is no closed form way of creating a distributed domain in a type-inferred / anonymous context, like:

const D = {1..n} dmapped MyDist;
var A: [{1..n} dmapped MyDist] real;

For this reason, it doesn't feel like a satisfactory replacement for dmapped to me

get rid of support for dmapped-style syntax?

Similarly, we could just retire, and not replace, dmapped, relying on factory methods. While this is sufficient, it seems unattractive to me, personally, for the reasons given at the top of this OP—it becomes the one type in the range/domain/array space that doesn't have a syntax for declaring a complete domain value (which is to say, one that embeds its distribution).

retain dmapped?

Of course, we could retain dmapped, though again, the main downside of this is that it has been considered non-intuitive, not very readable/verby ("1..10 domain mapped [by] Block"), and unpopular.