Hi Brad,
I think question 1 is a solid yes. {D} should be an associative domain
of domains. Having a compiler warning for this for at least one release
would be good.
I'm not opposed to requiring the braces for non-rectangular array
declarations, but I don't strongly either way on question 2.
David
On 01/24/2014 11:02 AM, Brad Chamberlain wrote:
> 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
------------------------------------------------------------------------------
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
