07-202r1
To: J3
From: Malcolm Cohen
Subject: Obvious contiguity flaws
Date: 2007 May 07
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 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 is not a .
o It does not contain a or .
o If its rightmost is a pointer, it has the
CONTIGUOUS attribute.
o Its final has nonzero rank.
o If it contains a ,
- all but the last is a colon;
- the last does not contain a ;
- no is followed by a
that is a ."
===END===