08-125 To: J3/WG5 From: Malcolm Cohen Subject: Coarray nomenclature Date: 2008 February 07 1. Introduction This paper contains two suggested changes to coarray nomenclature. They are independent and unrelated except for both being about coarrays. I'd like to thank both John Reid and Bob Numrich for their comments. 2. Suggestion One (Editorial) re Hyphenation The current hyphenation of the word "coarray" is inconsistent with the style we have chosen to use in the Fortran standard. In particular, our style demands not hyphenating the "non-" prefix ... obviously "nonco-array" is a nonstarter! There is no real need to hyphenate this word. Also, given the existence of what were briefly called "co-scalars", "co-array" is bringing the "arrayness" to the fore inappropriately. I've been thinking about this for a while, and recently I've always been writing it unhyphenated in my own papers/notes (to see how it looks/feels). Actually, although the very first time it looked a bit unfamiliar (since we have co- everywhere else!), I think it is a worthwhile improvement. The same applies to corank, cobounds, coshape, and codimension. (Most of these are an improvement over the hyphenated version in my opinion.) Bob Numrich commented "I agree we should remove all hyphenation. I used it initially, first to avoid the double vowel in coarray, and second to emphasize that the codimension is a different kind of dimension. My only lingering hesitation is whether people reading coarray for the first time might try to pronounce it coar ray. I think it is common practice to remove hyphenation once people get used to a new term and make it a new compound word. So we have contributed our bit to expand the richness of the English language." EDITS to 08-007: Globally replace "co-" with "co", except in any case where "co-" is not a coarray-related prefix. 3. Discussion on Suggestion Two (Semi-Technical) re CODIMENSION The codimensionality of an object really is something totally different from the dimensionality. The dimensionality actually replicates the (scalar) object. The codimensionality does no such thing; all objects of this kind are already replicated across images, the codimensionality is merely setting up an access method to get at the already-replicated object. Bob Numrich commented "I am still surprised at how difficult it is to get this point across. Whenever I give a talk on coarrays, I spend more time on this one topic than on anything else." (Comparing to CHARACTER length, the coarray attribute is no more DIMENSION than the character length is a "char-dimension".) Therefore, I think we ought to consider this the CODIMENSION attribute, and not lump it in with the DIMENSION attribute. Doing the latter has worsened the array attribute exposition (which I was trying to get into some semblance of order - with all our array categories it's just way too complicated!). Certainly we could say that DIMENSION[...] specified the CODIMENSION attribute (after all, INTERFACE specifies the EXTERNAL attribute). That would be an improvement, but it would be even better, I think, to split it off properly and use the CODIMENSION keyword. Of course we would still allow a coarray-spec in an entity-decl for overrides. Bob Numrich commented: "Adding a CODIMENSION attribute sounds OK to me. But would it be CODIMESION(p,q) or CODIMENSION[p,q] ? (or CO-DIMENSION[p,q] ?)" I would suggest continuing to use square brackets here so it looks the same as the syntax in coarray references. "If it's CODIMENSION[p,q], it seems like it doesn't add much that isn't already there with DIMENSION[p,q]. It just makes me type two more characters. I assume I will still be able to make a declaration like real :: x(m,n)[p,q] But using the other syntax, real, dimension(m,n), codimension[p,q] :: x requires a lot more typing. But I can see that it makes the difference in the two kinds of dimension much more explicit." Right, going for a separate CODIMENSION keyword has the disadvantage of more typing, but the advantage of being more explicit. The main goal here is to make the standard clearer, making programs clearer is useful but secondary. A third alternative would be to spell CODIMENSION as COARRAY; spelling DIMENSION as ARRAY was actually proposed back in F90 days but rejected as unnecessary redundancy given the prior existence of the DIMENSION statement, but we don't have that constraint here. Suggested straw vote 1: (1) Split the attributes (e.g. into the DIMENSION and CODIMENSION attributes), but use the same keyword (DIMENSION) for both. (2) Split the attributes and keywords (e.g. into DIMENSION and CODIMENSION). (3) Keep them together as they are now. (4) Undecided. Suggested straw vote 2 (if sv1 chooses option 2): (1) Use CODIMENSION. (2) Use COARRAY. (3) Use UNDECIDED. Outline of EDITS to 08-007: Split 4.5.4.2 "Array components" into two (note that this title is wrong if we don't split!). Split 5.3.7 "DIMENSION attribute" into two. Split 5.4.7 "DIMENSION statement" into two. Notes: (i) DIMENSION is only used outside of c04 and c05 in examples. (ii) There is no example of DIMENSION used to declare a coarray. We probably need more examples for the new stuff in any case. ===END===