# (j3.2006) Coindexed scalars, etc.

Whitlock, Stan stan.whitlock
Sat Jan 17 16:46:03 EST 2009

```I agree that co-indexed scalars should be allowed.  I expected them to be there already and was disappointed to see that they weren't.  Scalars are just rank-0 arrays, dudes!  Don't forget your APL.

Now about fields at co-indexed objects, does C(J)[p] mean "go get all of C from p and find element J" or does it mean "go to p, get C(J), and bring it back".  I thought it meant the second.

So that means that C(J)%X[p] is correct, ie, just "get field X from C(I) on p".

It gets weird when we throw in substrings and %RE and %IM:  C(J)%L(J:K)[p] says "get just the J:K substring from C(J)%L on p".  I'd prefer C(J)%L[p](J:K) so the substringing happens after you get C(J)%L from p.

Same with C(J)%Z%RE[p]  - you have to get just the real part of C(J)%Z from p.  I'd prefer splitting my complex numbers on my process after I get it from the other process, ie, C(J)%Z[p]%RE.

This question also affects type kind and length parameters for parameterized derived types:
TYPE A
INTEGER, KIND :: K
INTEGER            :: S
COMPLEX (KIND = K) :: Z
CHARACTER (LEN = S) :: L
END TYPE A
TYPE (A (4, 9)) :: C (5) [4]

I think that syntax is correct - if not, you know what I want to say:

What is C (J)%Z%RE%KIND[p] ?  C(J)%L%LEN[p]?  They're 4 and 9, of course, since the TYPE (A (4, 9)) :: C (5) [4] declaration happens on all processors.  But what if the 9 were an X?  Does X have to have the same value on all processes?

We could just simplify this discussion and not allow the type parameters and %RE, %IM, %KIND, and %LEN in the co-indexed object name?

Did I mention that coarrays are getting uglier, the more we polish F2008?

Sigh!				/Stan

-----Original Message-----
From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of Aleksandar Donev
Sent: Saturday, January 17, 2009 11:35 AM
To: fortran standards email list for J3
Subject: Re: (j3.2006) Coindexed scalars, etc.

Hello,
I think the [] should always go at the end, after all the local
selectors, including substrings, so I vote for c(i)(l:r)[p]. For %Re and
%Im I agree that they should be treated as components.
Aleks

Van Snyder wrote:
> 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.
>
> <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>
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http:// j3-fortran.org/mailman/listinfo/j3
>

--
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev
_______________________________________________
J3 mailing list
J3 at j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

```