07-202 To: J3 From: Malcolm Cohen Subject: Obvious contiguity flaws Date: 2007 May 01 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. 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] and [166:7.2.2.3p7]. 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.8p5], 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. Technical edits to 07-007r1 [92:5.3p5] Delete the definition of simply contiguous. [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 designator is <> if it is an which has the CONTIGUOUS attribute or is an array that is neither assumed-shape nor a pointer, or if it is an that satisfies the following conditions. o It shall not be a . o It shall not contain a or . o If its rightmost is a pointer, it shall have the CONTIGUOUS attribute. o Its final shall have nonzero rank. o If it contains a , - all but the last shall be a colon; - the last shall not contain a ; - no shall be followed by a that is a ." ===END===