(j3.2006) (SC22WG5.5638) Draft result of the interpretations straw ballot 11 and J3 letter ballot 35
John Reid
John.Reid
Sat Jan 9 08:31:34 EST 2016
WG5,
Here is a draft result of the interpretations straw ballot 11 and J3
letter ballot 35. Please let me know ASAP and certainly by 13 Jan (9
a.m. UK time) if I have omitted your ballot or make any errors in
copying it.
I have drafted conclusions, which need to be checked by /INTERP.
The comments on f08/0128 occupy more lines than all the rest put
together. I think this needs further J3 consideration.
Of the rest only f08/0144 is perhaps controversial. I have suggested
that Bob Corbett's change of wording for the edit be accept because it
accords well with the ANSWER.
On 19 Dec, I proposed this timetable:
19 Dec Interps ballot 10 ends
19 Dec Interps ballot 11 starts, and is also J3 ballot 35
23 Dec Corr vote ends
9 Jan Interps ballot 11 ends
13 Jan Corr vote starts
27 Jan Corr vote ends
30 Jan Corr sent to SC22
I was gambling on the interpretations being non-controversial. I think
this is the case for all the changes to the corrigendum resulting from
our vote on it (see N20xx, sent out yesterday) apart possibly from the
changes to 9.12 coming from the vote of Bob Corbett. And I think it is
true also for the changes coming from the interpretations vote, with one
possible exception, noted above.
I am therefore asking David to prepare a new version of the corrigendum.
Cheers,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N2093-1
Result of the interpretations straw ballot 11 and J3 letter
ballot 35 on Fortran 2008 interpretations N2091
NB This draft contains suggestions from John Reid for the decisions of
\INTERP.
Key for the Result line:
Y vote passes unconditionally.
C vote passes, subject to minor changes noted below
N vote fails. Returned to J3 for further work.
F08/ F08/ F08/ F03/ F08/ F08/ F03/ F08/
0128 0138 0139 0140 0141 0142 0143 0144
Bader N Y C Y Y Y Y Y
Chen Y C C Y Y Y C C
Clune Y Y Y Y Y Y Y Y
Corbett N Y C Y Y Y Y N
Kruyt C Y Y Y Y Y C C
Long Y C C C C Y C C
Maclaren Y Y Y Y Y Y
Muxworthy Y C Y Y C Y C C
Nagle Y Y Y Y Y Y Y Y
Reid Y Y Y Y C Y C Y
Shterenlikht Y Y Y Y Y Y Y Y
Snyder N Y C Y Y Y Y Y
Whitlock Y Y Y Y Y Y Y Y
Result N C C C C Y C C
Comments and decisions of /INTERP.
F08/0128
Reinhold Bader
I agree with the answers A1.- A3., except that in A1. "use associated"
should be replaced by "use association".
I disagree with the suggested edit, because it is too broad. Instead, I
suggest the following:
[275:9+] 11.2.3 Submodules,
"A submodule shall not directly reference its ancestor module
by use association. If a submodule indirectly references its
ancestor module by use association, every USE statement in its
body that causes such a reference shall specify an ONLY option.
An entity in the <only-list> for that option that is not a
generic specifier or a renamed operator shall not be specified
in the submodule's ancestor module. For an entity that is a
generic specifier or a renamed operator, the referenced
specific procedure (12.5.5.2) shall not be specified in the
submodule's ancestor module."
I'm hoping that this not only yields the same answers to the interp, but
also permits compile-time checking of any violations, avoiding the
complaint made by UTI 151 in 09-007. If this turns out to be unfixably
wrong, I'm willing to change my vote to "yes".
The rationale for the above suggestion is as follows:
Imagine that S(A) is a submodule of A (the ancestor) and wants to access
some other module {M} that may be a single module or the beginning of
a use-chain of modules. Prior to the interp, the following dependencies
are permitted, where (u) stands for use and (h) for host association:
-(u)---->{M}
/ |
/ (u)
/ |
/ v
S(A) --(h)---> A
With the interp's original edit, the line connecting one (or more) of
the modules in {M} and A causes the program to become non-conforming.
The alternative edit permits the programmer to avoid this with minimal
(if any) overhead.
During the London meeting it was pointed out that the dependency could be
avoided by restructuring the code and moving dependent parts to an
auxiliary module. This is true, but it may involve writing significantly
more code, and often also a submodule of the auxiliary module is needed.
As a result, the global code structure becomes more difficult to
understand.
Furthermore, if A implements "core" concepts that many other modules
might depend on (pushing code to S(A) wouldn't be needed otherwise), it
may well happen that the critical use association M->A gets established
later on in the development process, triggering a potentially large
amount of code restructuring (multiple submodules could be affected in
one fell stroke!). With the alternative edit, the only fallout is that
ONLY clauses must be added in S(A) if they're not already there anyway.
Robert Corbett
Answer A1 states that the example was not intended to be conforming.
Paper 09-141, which is cited in the discussion section, begins
The prohibition against a submodule accessing or
referencing its ancestor module by use association
appears to have been wrong-headed in the first place.
There appears to be no reason to keep it in any form.
I did not attend the meeting during which paper 09-141 was
approved, but I find it hard to believe that the committee could
have passed that paper without intending to allow such usage.
I see no technical objection to implementing the feature as it is
currently specified. Paper 09-141 contains remarks to that effect.
The comments Reinhold Bader included in his ballot convinced me
that the feature is useful, and that its removal will put a burden
on users. If the feature is retained, Q2 and Q3 need answers.
My reading of the Fortran 2008 standard as written is that the
answer to both questions is "yes".
On a minor note, the line
Note that the "submodule TR", Technical Report 19767 contains, an edit
does not conform to the rules of punctuation of American English.
In American English, the comma that terminates an appositive
phrase appears at the end of the phrase, not after the following
verb. Also, the appearance of quotation marks in that line would
be considered misuse in American English. It implies that the
term "submodule TR" has an unconventional meaning, which I do
not think is the case here
Erik Kruyt
In the light of F08/0142 the examples are incorrect due to the
augmented C1113. Change the module in the first example to e.g.:
Module m1
Interface
Module Subroutine mp1
End Subroutine
End Interface
Real x
End Module
Change the module in the second example to e.g.:
Module m2
Interface
Module Subroutine mp2
End Subroutine
End Interface
Real, Private :: a
Real, Protected :: b
...
End Module
Van Snyder
Upon reflection, I prefer an answer very similar to Option 1 in 15-208.
A proposed revision is:
{begin revision}
DISCUSSION:
The prohibition against a submodule accessing its ancestor module by use
association appears in the early drafts of Fortran 2008, up to 08-007r1.
Then it was modified by paper 08-154r1 creating a UTI (because the
modification was broken), and finally the requirement was completely
removed by paper 09-141.
ANSWER:
A1. Yes, the example is conforming. An edit is supplied to add this
extension to the Introduction, and to add normative text to clause
11 to make this completely unambiguous.
A2. Yes, A is still accessible by host association.
Subclause 16.5.1.4 paragraph 2 states
"If an entity that is accessed by use association has the same
nongeneric name as a host entity, the host entity is
inaccessible by that name."
This does not apply since A is not accessed by use association
(because it is PRIVATE and therefore not accessible by use
association, according to the final sentence of the second paragraph
of 5.3.2). Therefore, A can still be accessed by host association.
An edit is provided to revise the referenced sentence to make it
clear that the entity is accessible by use association but not host
association, rather than being completely inaccessible.
A3. No, the assignment to B is not conforming because, according to the
first sentence of the second paragraph of subclause 16.5.1.4, it is
accessed by use association, and therefore violates constraint C551
which states
"A nonpointer object that has the PROTECTED attribute and is
accessed by use association shall not appear in a variable
definition context..."
An edit is provided to add an explanation of this.
EDITS:
[xv] Introduction, p2, first bullet,
After "Submodules provide ... for modules."
Insert new sentence
"A submodule can reference its ancestor module by use
association."
[100:12] Second paragraph of 5.3.15 PROTECTED attribute, insert this
text immediately after the word "descendants" (i.e. before the comma)
"where it is accessed by host association".
[272:23] First paragraph of 11.2.2 The USE statement and use
association, after
"A module shall not reference itself, either directly or
indirectly."
Append to paragraph
"A submodule is permitted to reference its ancestor module by
use association. "
[273:2+4] Same subclause, NOTE 11.7, append
"If a submodule accesses a PROTECTED entity from its ancestor module
by use association, use of that entity is constrained by the
PROTECTED attribute (5.3.15).".
[443:36-37] Replace the first sentence of the second paragraph of
16.5.1.4 Host Association:
"If an entity that is accessed by use association has the same
nongeneric name as a host entity, the host entity is not accessed by
host association by that name."
{end revision}
The questions are simplified and combined.
I vacillated whether to change the edit for [100:12], viz.
"where it is accessed by host association"
to
"where it is not accessed by use association"
to try to make it clearer that construct association is not involved.
Ultimately, I did not change it, because both versions might be
perversely interpreted in that context. Perhaps some work is needed
here.
The edit for NOTE 11.7 is revised simply to draw attention to 5.3.15 to
refer to it by number instead of repeating material therein.
An edit is provided for [443:36-37] to revise the first sentence of the
second paragraph of 16.5.1.4p2, to make it clear that the entity B is
still accessible, albeit by use association:
"If an entity that is accessed by use association has the same
nongeneric name as a host entity, the host entity is not
accessed by host association by that name."
("... the host entity is inaccessible by that name" could be perversely
interpreted to mean the entity is entirely inaccessible by that name,
i.e., neither by host nor use association. The problem is the word
"entity.")
This edit would also clarify the situation wherein a host scoping unit
and an internal scoping unit also access the same entity by the same
name by use association (no submodules involved). I hope this doesn't
need another interp, something like
module M1
real, public :: X = 66
end module M1
module M2
use M1, only: X
contains
subroutine S1
use M1, only: X
implicit NONE
X = 42
end subroutine S1
subroutine S2
use M1, only: X
X = 42
end subroutine S2
subroutine S3
call S2
print *, X
end subroutine S3
end module M2
program P
use M2, only: S3
call S3
end program P
Is the assignment to X in S1 conforming? Assuming the program conforms,
what is printed by the PRINT statement in subroutine S3, i.e., is the
assignment to X in S2 an assignment to the entity in M1, or is X a local
entity in S2? According to 16.5.1.4p2, "If an entity that is accessed
by use association has the same nongeneric name as a host entity, the
host entity is inaccessible by that name." This could be interpreted to
mean that the entity X is not accessible in S1 or S2, neither by use
association nor by host association.
Decision of /INTERP: Returned to J3 for further work.
....................................................................
F08/0138
Daniel Chen
I agree with David and Bill's comment.
Bill Long
In the Question, replace "C456 in 007r1 reads" by "C465 in 10-007r1
reads".
{Fix typo in the constraint number, and be more precise about the
document number - there have been lots of 007r1's.}
David Muxworthy
In the question, 'C456' should read 'C465'.
Decision of /INTERP: Accept the suggested changes.
....................................................................
F08/0139
Reinhold Bader
I agree with Malcolm Cohen that inserting "containing the external
subprograms" after the word "fragment" occurring at the beginning of
the "QUESTION" section resolves an ambiguity.
Daniel Chen
I agree with Malcolm's extra edit.
Robert Corbett
The keywords "TRANSFER" and "zero-sized scalar" listed in the
KEYWORDS line of the header are not appropriate for the topic
of the interpretation.
Erik Kruyt
I agree with Bill Long that this needs a clearer example which
illustrates the localness of the procedure name.
Bill Long
In the Question, replace "Consider the program fragment" by "Consider
the program fragment containing the external subprograms".
{Clarify that these subprograms could not be internal or module
subprograms, with wording suggested by Malcolm Cohen. Alternatively,
include a complete program as the example, such as:
Subroutine s() Bind(C,Name='Hello')
Print *,'Hello'
End Subroutine
Subroutine s() Bind(C,Name='World')
Print *,'World'
End Subroutine
subroutine sub_hello ()
interface
Subroutine s() Bind(C,Name='Hello')
End Subroutine
end interface
call s()
end subroutine sub_hello
subroutine sub_world ()
interface
Subroutine s() Bind(C,Name='World')
End Subroutine
end interface
call s()
end subroutine sub_world
program test
call sub_hello()
call sub_world()
end program test
}
Van Snyder
Even though the title of the interp mentions "external procedure," I
agree with Malcolm Cohen that inserting "containing the external
subprograms" after the word "fragment" occurring at the beginning of the
"QUESTION" section clarifies the question.
Decision of /INTERP: Accept, subject to these changes:
1. Change keywords to "binding label, local identifier".
2. In the Question, replace "Consider the program fragment" by
"Consider the program fragment containing the external subprograms".
....................................................................
F08/0140
Bill Long
At the end of Q2, add a line
"Is the assignment permitted?"
{Since Q2 is not currently an actual "question", the answer is a bit
vague about what is "intended to be permitted".}
Decision of /INTERP: Accept the suggested change.
....................................................................
F08/0141
Bill Long
The first Edit should be at [24:11+] (and not at [22:11+]).
{And hence in the stated subclause. I assume previous changes have
removed or modified the last sentence of the previous paragraph in
10-007r1 "Any standard-conforming Fortran 2003 ... 1539".}
David Muxworthy
The first edit should be at [24:11+].
John Reid
The first edit is for [22:11+].
Decision of /INTERP: Accept the change suggested by Bill Long and
David Muxworthy.
....................................................................
F08/0143
Daniel Chen
I agree with David and Bill's comment.
Erik Kruyt
The example is in error.
Type(t), Intent(Out) x
should read
Type(t), Intent(Out) :: x
Bill Long
In the example code of the Question change
Type(t),Intent(Out) x
to
Type(t),Intent(Out) :: x
{Syntax rule R501. Agreeing with the comment of Erik Kruyt.}
David Muxworthy
I agree with John's comment. The interp should include the location
of the edit in 10-007r1.
John Reid
The edit is for [312:23+] which is in Clause 12.7, para. 2.
Decision of /INTERP: Accept the changes suggested.
....................................................................
F08/0144
Daniel Chen
I agree with Erik's comment.
Robert Corbett
The ANSWER section of the interp states
It was intended that nonadvancing input/output
not be permitted within a DO CONCURRENT construct.
An edit is provided to address this oversight.
However, the edit provided allows nonadvancing input/output
within a DO CONCURRENT construct in the case of child data
transfer statements. The final sentence of Subclause 9.6.2.4
of the Fortran 2008 standard states
A formatted child data transfer statement is a
nonadvancing input/output statement, and any
ADVANCE= specifier is ignored.
The answer might be changed to
It was intended that nonchild nonadvancing
input/output not be permitted within a
DO CONCURRENT construct.
for which the proposed edit is adequate. I prefer changing
the edit to
Nonadvancing input/output shall not occur (9.6.4.2)
in the range of the loop.
I included the subclause citation, because the word "occur"
is used in the sense specified in that subclause, not in
its conventional sense. I would not object to removing
the citation.
Erik Kruyt
The first WRITE statement with ADVANCE= in the example is (already)
not conforming due to C922.
Change the list-directed format specification to an explicit one, e.g.
write ( *, '(I5)', advance='NO' ) I
Bill Long
In program P for Q1, replace
write ( *, *, advance='NO' ) I
by
write ( *, '(I5)', advance='NO' ) I
{Constraint C922 requires an "explicit format specification".
Recommending the alternate version suggested by Erik Kruyt.}
David Muxworthy
I agree with Erik's comment.
Decision of /INTERP: Accept these changes:
1. In program P for Q1, replace
write ( *, *, advance='NO' ) I
by
write ( *, '(I5)', advance='NO' ) I
2. Change the edit to
"Nonadvancing input/output shall not occur (9.6.4.2)
in the range of the loop."
More information about the J3
mailing list