J3/06-353

Date: 3 November 2006
To: J3
From: Dick Hendrickson
Subject: Clause 5 Contiguous
References: J3/06-007R1

Questions prompted by reading the IS_CONTIGUOUS function. I
don't know what the intent was, so I have no edits.

87:21-22 I think this is over broad for the assumed-shape arrays.
As I read Clause 12, top of 311, argument association
is a two way street. The actual is associated with
the dummy and vice-versa. If this is true, than I think
87 disallow CALL SUB (CONTIGUOUS_ARRAY) unless SUB
has a contiguous argument. I think any old dummy array
(or scalar) should work.
EDITS: On line 21, replace "assumed-shape array" with
"assumed-shape dummy array"
On line 22, replace "contiguous object" with
"contiguous actual array argument".

88:15-21 This section is completely unparseable. Way too many
double and triple negatives and conjunctions. I think
something like
"the object has two or more elements which are not consecutive"
would be a reasonable replacement for (1) and (2) and then
"unless it is zero length character or a structure with
only zero sized things"
seem to be what (3) and (4) are trying to do.

In particular, is ARRAY(1:3:2) contiguous if it is a
zero length character array or is an empty derived type?


Technical specification changes.

1) I believe the text on 88 15-22 attempts to say that zero length
character strings and empty structure arrays are contiguous.

I think this is a mistake. Contiguous should only be a stride property.
We allow things like zero trip DO loops and zero size and length things
because zero is a natural limit and doing nothing is an appropriate
thing to do. But, for contiguity there is no natural limit. Having
a character array section suddenly become contiguous as the character
length goes to zero is not a natural limit. Furthermore, (I claim that)
there is no useful work to be done on an array section that is
contiguous if it is composed of things of zero size and not contiguous
otherwise.

If we don't special case zero sized internal parts, then the text
becomes clearer.

2) It is folly to allow contiguous to be processor dependent. Say
what we mean and mean what we say. Contiguous is (I suppose) meant to
be some sort of hint to the optimizer. It's folly to say the user might
give the wrong hint on some processors.

3) There is no reason to have scalars be contiguous. The attribute
only makes sense for assumed shape arrays and array pointers (that's
what 87:21-22 say). Since you can't associate a scalar with either
of those things, there is no reason to give them the attribute. It
just messes up the text. Making scalars uncontiguous is harmless now,
if we ever figure out a use for contiguous, then it's easy to go back
in a conforming way and apply that use to scalars also.

Proposed outline of edits:

Delete 88:15-22 And reword 87:23 to say something like
"An object is contiguous if it is an array and, if it has two or more
elements, the elements in array element order are consecutive. In
addition:
slightly edited laundry list from 87:24 to 87:14"

That describes it in terms of what is important and doesn't bury
the most important idea (consecutive in array element order) as
a clause in a double negative clause.