(j3.2006) Coindexed scalars, etc.

Van Snyder Van.Snyder
Fri Jan 16 20:47:13 EST 2009


Assuming we want coindexed scalars, substrings and complex part
designators, where do we want to put the image selector?  For a scalar
it's obvious.  For complex part designators, I think we want them before
%RE or %IM, as if they were components.

For substrings it's not obvious.  Do we want C(i)[p](l:r) or
c(i)(l:r)[p]?  It's a little bit weird to put the image selector in the
middle.  OTOH, by putting it there, we can use <data-ref> to grab the
constraints on <image-selector>.  Perhaps <part-ref> should have been
<part-name> [<image-selector>] [(<section-subscript-list)] -- but this
would break existing implementations.

Malcolm's message yesterday didn't edit the productions for substrings.

The suggestion here replaces <object-name> in R601 instead of adding
<coindexed-named-object>.

I believe the following covers coindexed scalars, coindexed complex
parts, coindexed type parameter inquiries, and coindexed substrings.
Adding coindexed whole arrays is trivial (just remove the proposed
constraint C600a).

R601 <designator> <<is>> <non-substring-designator>
                  <<or>> <substring>

R601a <non-substring-designator> <<is>> <data-ref>
                                 <<or>> <array-element>
                                 <<or>> <array-section>
                                 <<or>> <complex-part-designator>
                                 <<or>> <structure-component>

C600 (R601a) A <section-subscript-list> shall not appear in <data-ref>.
{This blocks C624 from the general case.  We don't need to say "exactly
one <part-ref>" because the constraint on <structure-component> says
"more than one".}

C600a (R601a) The <data-ref> shall be scalar if an <image-selector>
      appears.
      {I believe this constraint is harmful.}

R609 <parent-string> <<is>> <scalar-non-substring-designator>
                     <<or>> <scalar-constant>





More information about the J3 mailing list