07-202r2 To: J3 From: Malcolm Cohen Subject: Obvious contiguity flaws Date: 2007 May 09 1. Introduction "always-contiguous" is quite a poor term for several reasons: - it doesn't mean things that are always contiguous, that is, it does not mean what it says; - it is apparently hyphenated to distinguish it from the plain meaning of the words; this kind of non-standard usage should be avoided. Or perhaps the hyphenation was because it's an adjectival phrase, in which case it's simply mistaken (i.e. wrong); we hyphenate these only when the whole thing is a noun, not just because this use is an adjectival phrase. (And seeing how often we have gotten it wrong, it's not a good practice anyway.) There are also obvious technical flaws in the definition, which is simultaneously unreasonably strong (rules out things which are obviously contiguous) and too weak (allows things which are obviously not contiguous). Well, I suppose just "wrong" is a better description... 2. Replacement discussion The concept this was replacing was "compile-time contiguous", which admittedly was also a very poor choice of words! However, what it is describing is not in fact the set of things which contiguous at "compile time" (whatever that is) - there are plenty of examples which are not only technically contiguous at compile time, but for which the proof is totally obvious. So that's not what it is describing -- so what is it describing? Well, it is describing things that are not only contiguous, but that the contiguity is simple enough so that the processor can work it out without needing a degree in logic. That is, it is not just contiguous but *simply* contiguous. So I propose the term "simply contiguous" as a replacement. This kind of use of the word "simply" is not unusual, for example it is fairly common in maths. 3. Obvious technical flaw The definition of "simply contiguous" is obviously flawed in its requirements on its base object: it requires it to have the CONTIGUOUS attribute or not to be a pointer or assumed-shape array. It is unreasonably conservative in that the following are all "obviously contiguous" but don't satisfy the definition: scalar_pointer%explicit_shape_array_component any_2dim_array_whatsoever(i,j)%explicit_shape_array_component Note that "base object" is "the data object whose name is the leftmost part name". That is the whole of any array variable, even if we just took an element of it. Furthermore, the following items are obviously not contiguous, in particular scalar%arraypointer(:) is allowed. In fact the focus on the base object is just wrong. We already said the rightmost is the only one which has nonzero rank, so *THAT* is the item to focus on. 4. Less obvious technical flaw "simply contiguous" should be applied to the designator, not the object itself. This can be easily seen by considering REAL,TARGET :: x(100) REAL,POINTER :: p(:) p=>x Here, the target of p is both "simply contiguous" and not "simply contiguous". This is *NOT* an acceptable situation! Looking at the definition, it is pretty obvious that it should be applied to the designator and not the object seeing as how nearly all the requirements are on the designator and not on the object. 5. Editorial flaws in the definition Obvious ones are - "It" used to refer sometimes to the object, sometimes to its designator. - Spurious "Only" in the penultimate item; contiguity only has meaning for arrays. 6. Name change and associated editorial edits to 07-007r1 The wording change is nearly trivial - change "always-contiguous" to "simply contiguous" everywhere it appears (only 5 places). It is trivial at [92:5.3.6p5+0] (but see replacement below) and at [166:7.2.2.3p8]. At [314:12.5.2.5 C1238], "is not a pointer array and is not always-contiguous (ref)" -> "is a nonpointer array that is not simply contiguous (ref)" {Was broken before - it said that scalar actual arguments had to correspond to assumed-shape dummy arrays.} At [316:12.5.2.8p4], simplify and replace with constraint: "C12nn The actual argument corresponding to a dummy pointer with the CONTIGUOUS attribute shall be simply contiguous (ref)." {Yes, I think this should be a constraint.} [316:Note 12.31] Delete - it is not relevant specifically here, it is relevant to all contexts where simple contiguity is required! Reinstate the note as an example following the definition of "simply contiguous", modifying the comments as necessary, replacing the first paragraph with "Array sections that are simply contiguous include column, plane, cube, and hypercube subobjects of a simply contiguous base object, for example:" and replace the last sentence of the note with "All simply contiguous designators designate contiguous objects.". Also change the remaining instance of "compile-time contiguous" to "simply contiguous". This is at [317:12.5.2.9p3+1]. 7. Edits to 07-007r1 fixing the "Less obvious" technical flaws [92:5.3.6p5] Delete the definition of simply contiguous. {This technical edit replaces the above editorial fix to the same para.} [126:6.2.3prior] Insert new subclause 6.2.3 immediately before the existing 6.2.3 as follows. "6.2.3 Simply contiguous array designators A specifies a simply contiguous section if and only if it does not have a and o all but the last is a colon, o the last does not have a , and o no is preceded by a that is a . An array designator is <> if and only if it is o an that has the CONTIGUOUS attribute, o an that is not a pointer or assumed-shape, o a whose final is an array and that either has the CONTIGUOUS attribute or is not a pointer, or o an array section - that is not a , - that does not have a , - whose final has nonzero rank, - whose rightmost has the CONTIGUOUS attribute or is neither assumed-shape nor a pointer, and - which either does not have a , or has a which specifies a simply contiguous section. An array is simply contiguous if and only if it is a simply contiguous array designator or a reference to a function that returns a pointer with the CONTIGUOUS attribute." ===END===