(j3.2006) Pure subroutine musings

Malcolm Cohen malcolm
Tue Aug 22 02:57:33 EDT 2017

We have a constraint (in F2008 as well as in the current CD):


  "In a pure subprogram any designator with a base object that is . a
coindexed object . shall not be used . in a variable definition context ."


Several points here:

1.	Coarrays are required to be SAVEd or ALLOCATABLE.  SAVEd ones
already cannot be written to.  Local ALLOCATABLE ones cannot be allocated
(image control statement prohibition) so they are irrelevant.  Out-of-scope
ones already cannot be written to.  This leaves coarray dummy arguments
2.	Ok, so a pure subroutine can have an INTENT(INOUT or OUT) dummy
coarray.  Writing to that will have an effect visible elsewhere, whether or
not you write to a coindexed subobject of it.  So what is it that is bad
about writing to a coindexed subobject of it?  How does this differ from
writing to elements of arrays?  I note that due to the segment rules you
already cannot do anything bad within the scope of the pure procedure
(whether the co-elements are on your image or on some other image, no other
image is allowed to read your effects because there are no image control
statements allowed inside a pure procedure).
3.	However, all of the places where impure procedure invocation is
prohibited still permit an actual argument to be a coindexed object.  So
this is still going to achieve (probably on procedure return) writing to a
coindexed object in a context where purity is required.  Surely if purity
requires no coindexed variable modification (yet to be shown?), it would be
bad to allow it in the other places.  But the other places manifestly permit


Perhaps this "no coindexed updating in a pure procedure" is just supposed to
be "good coding practice", i.e. we think it would be too complicated to keep
track of?


To elaborate on (2) a bit more, the purpose of the purity rules is not just
so that there are "no side effects", it is so that separate pure procedure
invocations, whether the same pure procedure or not, cannot communicate (and
this is forced at compile time), and so can safely be executed in parallel
etc.  But if we ignore the segment rules, this is *not* the case when
coarrays are involved, even if no coindexed writing occurs - just coindexed
reading.  And if we trust in the segment rules, coindexed writing is already
prohibited when another image reads it in an unordered segment.  I just
don't see how this constraint helps, unless we also prohibit coindexed


Here is an example which violates the constraint.  I note that of the two
compilers I have access to which claim coarray support, only one produces a
diagnostic for this.


Program q4

  Real x[*]

  Call pure(x)

  Sync All

  Print *,'FAIL',x


  Pure Subroutine pure(y)

    Real,Intent(InOut) :: y[*]

    Integer nextimage

    next_image = Mod(this_image(), num_images()) + 1

    y[next_image] = next_image

  End Subroutine

End Program


Is there something I'm missing here?




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


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

More information about the J3 mailing list