All:
This is a bit off-the-wall, but I'd like to think of a domain as a tuple of
index sets (one tuple member per dimension). A domain variable and its literal
representation should be interchangeable. That argues for removing the case
where the optional curly braces may be supplied.
As a degenerate case, a single set would be interpreted as a one-tuple, so the
parens used to form a tuple could be omitted in that case.
In general, I would expect that a set of integers could be described by a
combination of individual indices and ranges:
1, 3..5, 7, 10..12, etc.
Modulo allowing ranges to represent regular sequences of indices, I believe
that this is equivalent to an associative domain. That would mean that
enclosing the above in curly braces makes good syntactical sense.
{1, 3, 4, 5, 7, 10, 11, 12, etc. } // An associative domain literal (in
canonical form).
A rectangular domain is then simply a special case of associative domain that
can be represented by a single range.
A range expression should therefore be accepted as a valid domain expression,
without parentheses.
So, in particular my answers to the two questions posed are:
1. Yes. If D has type "set of indices", then {D} having type "set of set of
indices" seems to make good sense. I can even imagine a use for such a set.
2. Yes and No. Given my argument that ranges are already sets, they don't
require braces, but sequences of indices do. So in canonical form,
var A : [1..n] real;
is acceptable, but
var A : [1, 2] real;
is not. In the language the type of the thing lying in the square brackets
should be "domain"=="tuple of index sets". So to accept the first version, we
already have to reduce range to "index set" and a single index set to a
one-tuple of index sets. That will make the parser happy. (This almost
suggests that square brackets rather than parentheses should have been chosen
to represent tuple literals....)
Considering the second declaration in the same way, it for sure looks like a
tuple, but "1" and "2" do not look like index sets. We could allow single
integers to be promoted to index sets, in which case this would represent a 2-D
array with a single element at coordinate (1,2). This could be particularly
useful for representing degenerate slices of multidimensional arrays.
Compare that with:
var A : [{1,2}] real;
which we would have to interpret as a one-dimensional array containing two
elements.
In my world -- in which ranges are shorthand for a sequence of indices --
ranges would be flattened when included in a larger set. Otherwise, combining
integers and ranges in a set
{ 1, 3..5, 7, 10..12, etc. }
would yield a type mismatch -- assuming that all of the indices in a domain
must be of the same type.
Therefore, not requiring the brackets would introduce a parsing ambiguity. Does
var A : [1, 3..5, 7, 10..12] real ;
mean a four-dimensional array containing 9 elements? or a one-dimensional array
containing 8 elements?
I would choose the former and require the curly braces to force the latter
interpretation:
var A : [{1, 3..5, 7, 10..12}] real;
(Now definitely a one-dimensional array.)
The interpretation of a domain as a tuple of index ranges is consistent with
current syntax, in which one need only write
var A : [1..n, 1..n] real;
to specify a square, n x n array.
THH
________________________________________
From: Brad Chamberlain [[email protected]]
Sent: Friday, January 24, 2014 9:02 AM
To: Chapel Sourceforge Developers List
Subject: [Chapel-developers] Request for review (concept and code): Domain
expression cleanup
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
