(j3.2006) Annoying wording in THIS_IMAGE

Malcolm Cohen malcolm
Wed Aug 23 03:42:03 EDT 2017


Hi folks,

 

"The result of THIS_IMAGE (COARRAY [, TEAM = TEAM]) is the sequence of
cosubscript values for COARRAY."

 

But what if COARRAY cannot have any cosubscripts, e.g. in

Program q5h

  Type t

    Real r

  End Type

  Type(t) x[123:456,789:*]

  Print *,This_Image(),This_Image(x)

  Sync All

  If (This_Image()==1) Print *,'*****************'

  Sync All

  Print *,This_Image(),This_Image(x%r)

End Program

 

In this case, x%r is not a cosubscriptable object.  There are no possible
cosubscript values for it!

 

So either this is not conforming, or we're going to have to invent some
semantics.  At least one compiler rejects this anyway, claiming "x%r" is not
a coarray.

 

We do say explicitly that x%r is a coarray in 5.4.7 Coarray:

"A subobject of a coarray is a coarray if it does not have any cosubscripts,
vector subscripts, allocatable component selection, or pointer component
selection."

 

In the case of the subobject being an array section or array element there
are (weakly) implied cobounds from

                "If image-selector appears, the number of cosubscripts shall
be equal to the corank of part-name."

This could be thought to imply you'd get the cobounds from part-name too;
OTOH that is a pretty weak implication, too weak for a standard - this needs
to be stated explicitly.  But in this case (array sections and array
elements), I am in no doubt whatsoever that the codimensions of the
subobject are supposed to be those of the base coarray.

 

But seeing as how one cannot cosubscript a component of a coarray, the above
gives no implication at all for the cobounds of X%R.

 

I note that I've complained earlier about similar poor wording in LCOBOUND
and UCOBOUND.  If we were taking the coarray analogy to arrays seriously,
we'd be saying that in the case of a subobject, the lower cobounds are all
equal to 1, and the upper cobounds equal to the coextent.  The same compiler
that objects to THIS_IMAGE(x%r) also objects to LCOBOUND(x%r). 

 

I assume that we do want to allow x%r to be argument-associated with a
coarray dummy argument, which certainly requires it to be a coarray (but
does not depend on the corank, let alone the cobounds, since the dummy has
its own declaration thereof).

 

But that means allowing LCOBOUND, THIS_IMAGE and UCOBOUND on it, so we need
to specify, either in 5.4.7 what the codimensions and cobounds are of such a
subobject of a coarray, or in the intrinsics themselves to say that they
magically apply themselves to the base coarray.

 

So for example, we could insert in 5.4.7, wording like

  "A subobject of a coarray that is itself a coarray has the same
codimensions as the base coarray."

 

If we wanted to follow the array analogy, we'd then follow it up with

  "If the subobject is a component of a coarray, its lower cobounds are
equal to one; otherwise, its lower cobounds are equal to those of the base
coarray."

 

Or if we want to have the intrinsics magically giving the answer for the
base coarray (I do not see why this is attractive - just leave the subobject
selector off if that's what you want!!!), then instead follow it up with

  "The cobounds of the subobject are equal to those of the base coarray."

 

(Note: I think the meaning of "base coarray" in these sentences is clear
enough not to need any special term or definition, since we're already
talking about a coarray with a subobject thereof, and it's not used anywhere
else.)

 

Is there any chance of unanimous agreement on how to fix this ambiguity
(present in F2008)?  Or do I have to submit an interp?

 

Oh, and the wording in THIS_IMAGE *still* needs fixing, whichever way we go,
because not being a cosubscriptable object, whatever we say in 5.4.7 does
not help how it is stated in THIS_IMAGE!  Maybe that really does need to use
"base coarray", or maybe someone can come up with an alternative wording
that does not rely on cosubscripting the actual argument.  (I'm willing to
work on this, but resolution of the underlying lack of specificity in 5.4.7
needs to come first I think.)

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170823/c074b466/attachment-0001.html 



More information about the J3 mailing list