J3/06-353r1

Date: 2006/11/16
To: J3
From: Malcolm Cohen
Subject: Clause 5 Contiguous
References: J3/06-007r1

This paper answers the questions from 06-353.  We have edits.

Q. 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.

A. We agree.

EDIT. [87:22] After "with a contiguous",  "object" -> "effective argument"


Q. 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.

A. The suggested replacement for (1) and (2) is obviously defective in
   the case of an array with 3 elements, since 2 of them will perforce not
   be consecutive whether the array is contiguous or not.

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

A. That is not specified by the text at 15-21 and it is therefore
   processor dependent whether that object is contiguous.

   The specification at 88:15-21 of how some objects are not contiguous
   is not intended to be anywhere near comprehensive.  It's purpose is
   to ensure that it is more work for the compiler writer to provide a
   defective IS_CONTIGUOUS function than to get it right, by requiring
   the right answer in some obvious cases.

Technical specification changes.

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

A. The text does not say that.  There is no intention of saying that.
   See above.  The exclusions of zero-sized things from 88:15-21 have
   the effect of putting them into the processor-dependent category,
   where they belong.

Q. 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.

A. Memory layout, and in particular, padding in structures, is processor
   dependent.  Since contiguous is a memory layout property under component
   selection, processor dependent is what we want.

Q. 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.

A. Agreed.  Furthermore, it appears that contiguity makes little or no sense
   for zero-element and 1-element arrays; and specifying such arrays to be
   contiguous would impose an implementation cost (runtime test) on IS_CONTIGUOUS,
   we propose putting such arrays into the "processor-dependent" category
   of contiguityness.  (In the one-element and zero-element array section
   cases, the usual contiguity test gives you the contiguity of the base object
   instead of that of the section.)

EDIT. [87:25] Delete.
{Scalar removal.}
      [88:4] Append "or".
      [88:5] Delete.
{0/1 elt array removal.}

===END===