(j3.2006) (SC22WG5.5476) J3/15-159 - J3 Fortran interp letter ballot #33 - due 24-Apr-2015

[Van Snyder]

On Sun, 2015-03-29 at 16:41 +0000, Whitlock, Stan wrote:

> The following Fortran interpretations are being balloted:
> 
>  
> 
> Yes  No   Number    Title
> 
>  
> 
> -Y-  ---  F08/0126  Can cobounds be referenced in the same type
>                                  declaration?
> 
> -Y-  ---  F08/0127  May an initial line begin with a semicolon?
> 
> ---  -N-  F08/0128  Is recursive USE within a submodule permitted?

Answers to and edits for Q1 and Q2 are not problematic.  The answer to
Q3, that an entity with the PROTECTED attribute that is accessed in a
submodule by use association from its ancestor module is not definable
introduces a contradiction in 5.3.15.  C551 and C552 clearly state that
an entity that has the PROTECTED attribute and is accessed by use
association shall not appear in a variable definition or pointer
association context.  5.3.15p2, however, makes an exception for
descendants of the module in which the entity is given the PROTECTED
attribute.  The submodule TR did not envision that the ancestor module
would be accessible by use association, and therefore no contradiction
arose, at least not one related to submodules.  Since this is an
entirely new concept, not envisioned in the TR, the answer to Q3 could
go either way.  I prefer that the answer be that a protected entity is
not protected in a submodule of the module where it is given the
attribute, even if it is accessed therein by use association.  To that
end, constraints C551 and C552 should be revised to begin in the same
way that 5.3.15p2 begins, viz. "Other than within the module in which an
entity is given the PROTECTED attribute, or within any of its
descendants...."  If we truly desire that a protected entity accessed
from the ancestor module by use association be protected, then 5.3.15p2
needs attention to remove the inconsistency between it and C551/C552,
viz. "Where an entity is accessed by use association, if it has the
PROTECTED attribute in the module from which it is accessed then".

There is an additional problem here, that is properly the topic of a
different interpretation because it is not related to submodules.
Suppose a variable is declared in a module.  Suppose it is accessed by
use association in another module, and given the PROTECTED attribute
there.  5.3.15p2 appears to make it undefinable in the module in which
it is originally declared.  This is absurd.  Either 5.3.15p2 needs
revision, or it should be prohibited to confer the PROTECTED attribute
upon an entity that is accessed by use association.

> -C-  ---  F08/0129  Is CLASS(type) required to refer to a prior type
>                                  definition?

The TITLE: line for F08/0129 in 15-159 (and eventually 006) needs to be
filled.

> -C-  ---  F08/0130  Does coarray allocation sync even with stopped
>                                    images?

Edit instructions for [131:17-18] are inconsistent with the exposition
of the entire revised paragraph.  In the revised paragraph, insert
"apart from STAT_STOPPED_IMAGE" before "occurs" in the third line.

> -Y-  ---  F08/0131  Are the changes to C_LOC in the 2010 revision
>                                   intentional?
> 
> -Y-  ---  F08/0132  Can a procedure pointer be declared with an
>                                   interface block?
> 
> -Y-  ---  F08/0133  Is unallocated actual associated with
>                                      nonallocatable dummy OK?
> 
> -Y-  ---  F08/0134  <stat-variable> in an image control statement
> 
> -Y-  ---  F08/0135  Vector subscripted actual makes VALUE dummy
>                                    undefinable?
> 
> -Y-  ---  F08/0136  Argument correspondence with VALUE and
>                                   ASYNCHRONOUS
> 
> -Y-  ---  F08/0137  Result of TRANSFER when MOLD is an array with
>                                   element size zero