Hi Chapel Devs --
This is a request for a proposed change to the interpretation of Chapel
programs, which anyone invested in the language should give a quick look
at and then respond to two questions below. There's also a patch to
implement the change (which I'll need a reviewer for as soon as we verify
that we have consensus on it).
For some time now, Chapel has permitted a domain to be specified either
by naming it, e.g.:
const D = {1..n};
const DistD = D dmapped Block(...);
forall i in DistD ...
or by wrapping it in an extraneous set of curly brackets:
const D = {1..n};
const DistD = {D} dmapped Block(...);
forall i in {DistD} ...
The reasons for this are somewhat obscure (and arguably indefensible), but
relate to (1) a precedent set in ZPL, (2) the days when we used square
brackets for domain literals, and (3) to the use of anonymous domains in
array declarations without curly brackets (i.e., a pure implementation of
Chapel would require
var A: [{1..n, 1..n}] real;
rather than permitting the shorthand:
var A: [1..n, 1..n] real;
I'd forgotten about this anomaly until doing cleanup on iterations over
anonymous domains the other week when I encountered some instances of it.
Over lunch, Vass pointed out that cleaning this up should be fairly easy
so I took it on as a five-minute fix (TM).
I'm proposing that instead, we interpret {D} (where 'D' is a domain) as an
associative domain of domain values, containing one index 'D' which seems
more consistent with the current language definition.
In implementing this, I also realized for the first time (or re-realized
something I'd forgotten), that as an extension to the sugaring of
anonymous domains in array declarations, that we permit:
var A: [1, 2, 4] real;
to mean "A is declared over an anonymous associative domain {1, 2, 4}. I'm
not sure whether this is a good thing or not. I think the argument for
sugaring this case is weaker since programmers from C and Fortran won't
have a corresponding concept that they'll expect to work in Chapel, and I
think in this case the curly brackets make the intention clearer:
var A: [{1, 2, 4}] real;
That said, my patch does not impact this behavior -- it's more a question
for future five-minute fixes (TM) because it would be similarly
straightforward.
So, the two questions are:
1) Should we interpret {D} as an anonymous associative domain of domains
rather than simply a reference to domain 'D'?
2) Should we require curly brackets for anonymous domains in array
types that are not rectangular / defined by a list of ranges?
And if you're not interested in reviewing the patch, you can stop there.
-----
The heart of the patch is a simple change: We have traditionally
supported a routine, chpl__buildDomainExpr() which creates a domain from
whatever is passed it. One of the overloads took a domain and simply
returned it which is what caused '{D}' to evaluate to 'D'. So the idea
behind this change is to remove that overload.
A little more work is required, however, because the same call is used to
build the domain for an array type like '[D] real' and in this case, we
want to permit a domain like 'D' to be used. So what I did was to split
this call into two calls:
chpl__buildDomainExpr() : does what it has, but without the domain
overload now
chpl_ensureDomainExpr() : used in the array type signature context
to make sure that the expression is a
domain. In this context, if the thing
is a domain, we simply return it. In
all other cases, we forward the args to
chpl__buildDomainExpr()
>From there, the only other change was to switch calls to
chpl__buildDomainExpr() in the array type signature case (which was most
of them) over to chpl__ensureDomainExpr(), and to rewrite any tests that
were relying on '{D}' evaluating to 'D'.
I also added a test to demonstrate the "anonymous associative domain in an
array declaration" issue for consideration.
Note that to only permit rectangular domains to have their curly brackets
dropped in the array declaration context, we'd simply need to restrict the
type signatures permitted for chpl_ensureDomainExpr(), I believe. And we
could generate an error overload for the other cases.
Thanks,
-Brad
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
