(j3.2006) (SC22WG5.4829) Result of the interpretations ballot 4
John Reid
John.Reid
Thu Oct 11 06:12:39 EDT 2012
WG5,
Here is the latest draft result of interpretations ballot 4. The only
changes since the previous version come from Malcolm. I had included as
"Responses from the editor" comments that were intended only as email.
He has provided revised comments.
There remains the task of choosing the result of all the ? items. I
propose that they all be C, so that J3 decides what to do about them at
its meeting next week. What does \interp think about this?
Cheers,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N1944-3
Result of the interpretations ballot 4, N1934
Key for the Result line:
Y vote passes unconditionally.
C vote passes, subject to J3 considering the comments and reasons
and making no change that alters the technical content.
N vote fails. Returned to J3 for further work.
? result will be decided by the Convener and /INTERP.
The comments are given in alphabetic order, which
sometimes causes forward references to later comments.
F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/
0043 0048 0054 0055 0056 0057 0058 0059 0060 0061
Chen Y Y Y Y Y Y Y Y Y Y
Cohen Y N Y C Y Y Y Y Y Y
Corbett Y C N Y N Y N Y Y Y
Long Y C Y C Y Y Y C Y Y
Maclaren - Y Y - - Y Y - Y Y
Muxworthy C Y C C Y C Y Y Y Y
Reid Y Y Y Y Y Y Y Y Y Y
Snyder Y Y Y Y Y C C Y Y Y
Whitlock Y Y Y Y Y Y Y Y Y Y
Result C ? ? C ? C ? C Y Y
F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/ F08/
0062 0063 0064 0065 0066 0067 0068 0069 0070 0072 0073
Chen Y Y Y Y Y Y Y Y Y Y Y
Cohen Y Y Y Y Y Y Y Y Y Y C
Corbett Y N C Y Y C Y Y Y Y Y
Long Y Y C Y Y Y C Y Y C Y
Maclaren Y C Y C - - - - - Y -
Muxworthy Y Y Y Y Y Y Y Y Y Y Y
Reid Y Y Y Y Y Y Y Y Y Y C
Snyder Y Y Y Y Y C Y Y Y Y Y
Whitlock Y Y Y Y Y Y Y Y Y Y Y
Result Y ? C C Y C C Y Y C C
Comments and reasons for NO votes
F08/0043
Muxworthy comment:
Why not remove C1229 now? It takes only three small edits.
Reply from the editor:
Because there is no defect in the standard so it would be an
unnecessary edit. Editorial fixes like removing redundant text is more
efficiently done via the editorial process for the next revision.
(It might not necessarily be best to remove the specific redundancy
identified by the interp question.)
....................................................................
F08/0048
Cohen reason for NO vote:
Bill Long writes:
"Does the interp open the door to a whole room full of "clever
programming" opportunities? For example, you can pass a different
element on each image."
Yes, that is precisely why I voted against this interp at every
previous opportunity. I think it is a bad idea to provide such a
confusing feature with so few redeeming qualities.
Corbett comment:
While I see no problem with implementing the feature as described in
the proposed interpretation, I would agree to defer approval of the
interpretation until after further consideration of Malcolm's
objections.
Long comment:
I think it would be clearer if the last word of the edit
were changed from "array" to "coarray". I know that further
restriction could be deduced from 12.5.2.8p1, but why be unnecessarily
obscure?
Does the interp open the door to a whole room full of "clever
programming" opportunities? For example, you can pass a different
element on each image. An only slightly more complicated example than
the outline in the interp is:
program test
interface
subroutine sub (x)
real x(10)[*]
end subroutine
end interface
real :: x(100)[*]
integer :: ti
ti = this_image()
x = 666
call sub (x(ti))
print *, "For image ", ti, "x(1:15) = ", x(1:15)
end program test
subroutine sub(y)
real y(10)[*]
y = 999
end subroutine sub
Testing this out does lead to the expected results:
> aprun -n4 ./a.out
For image 3 x(1:15) = 2*666., 10*999., 3*666.
For image 4 x(1:15) = 3*666., 10*999., 2*666.
For image 2 x(1:15) = 666., 10*999., 4*666.
For image 1 x(1:15) = 10*999., 5*666.
>
If sub contained coindexed references to y, it could get confusing
about what elements of x you are really accessing on the remote
images. In principle this is OK, but I wanted to be sure we were all
agreeing to the same consequences for this interp.
Reply from the editor re: Changing "contiguous array" to
"contiguous coarray":
The editor will change it back, since that would make this sentence
confusing and at the same time partially duplicate the technical
content of the previous sentence. It is ALWAYS a bad idea to
duplicate requirements!
There is no obscurity, the previous sentence is perfectly clear.
It does not have to be stated again.
....................................................................
F08/0054
Corbett reason for NO vote:
I think that the proposed interpretation is a misinterpretation of
what was intended by paper 02-144. As I have said before, I think
that the paper was sloppy in that it did not mean a procedure
reference when it used the term "referenced." I think that by
"referenced," it meant any use other than a declaration.
Nonetheless, I think the difference between the proposed
interpretation and what I think was intended in the paper is
small enough that I would not vote "no" on this interpretation for
that reason.
The reason I am voting "no" on this interpretation is that the
proposed edits are incorrect. The text of the relevant portion of
the standard is also erroneous.
I assume that the term "procedure identifier" is meant to include
operators and the names of procedures and procedure pointers. The
problem is that a generic identifier appears to fall under this
definition. A generic identifier does not have either implicit or
explicit interface. I do not see how the proposed edits apply in
the case of a generic identifier.
As I thought about the issue, I convinced myself that the property
of having implicit or explicit interface should apply only to the
names of procedures and procedure pointers, and not to procedures
themselves. Because of renaming, a single procedure can have more
than one name in a given scoping unit. The properties of each name
might be different. For example, a function F might be identified
by the names G and H in a scoping unit. The names of the dummy
arguments of G and H might be different.
Reply from the editor:
>
> I think that the proposed interpretation is a misinterpretation of
> what was intended by paper 02-144.
Paper 02-144
***DID NOT INTEND TO MAKE A TECHNICAL CHANGE***
Not even a small one.
(Either that or the authors secretly wanted a technical change and got
it past the committee by subterfuge. I do not believe that is the case.)
...
> The reason I am voting "no" on this interpretation is that the
> proposed edits are incorrect. The text of the relevant portion of
> the standard is also erroneous.
>
> I assume that the term "procedure identifier" is meant to include
> operators and the names of procedures and procedure pointers. The
> problem is that a generic identifier appears to fall under this
> definition. A generic identifier does not have either implicit or
> explicit interface.
Huh? The edit says
"Within the scope of a procedure identifier, THE PROCEDURE shall have
an explicit interface"
Nothing about generic identifiers having an explicit interface.
> I do not see how the proposed edits apply in
> the case of a generic identifier.
Seems clear enough to me.
> As I thought about the issue, I convinced myself that the property
> of having implicit or explicit interface should apply only to the
> names of procedures and procedure pointers, and not to procedures
> themselves. Because of renaming, a single procedure can have more
> than one name in a given scoping unit. The properties of each name
> might be different. For example, a function F might be identified
> by the names G and H in a scoping unit. The names of the dummy
> arguments of G and H might be different.
They would still both have explicit interfaces though...
I am reluctant to completely rewrite the way the standard describes
interfaces to procedures along the lines suggested, in an interp.
I agree that the language could be better, but apart from not being
entirely convinced that the suggested approach would actually be an
improvement, I think that the right time for rewriting the whole
method of description must be in a revision, not an interp.
Muxworthy comment:
In the first edit shift 'only' four words to the right?
Reply from the editor:
ok (the original is also ok, but this is marginally nicer).
....................................................................
F08/0055
Cohen comment:
In the edits, change "with d==0" to "with d equal to 0", twice.
Long comment:
Particularly for an interp about G output formatting, it
would be very helpful to actually display the expected output.
[Generally, when there is example code that has output, it would be
helpful to state the correct output if the code is claimed to be
conforming.]
Muxworthy comment:
Is it preferred style to use 'd==0' in narrative English in the edits
(twice), rather than d=0? d is not a variable (although it could be
represented by a character variable).
Reply from the editor:
I take your point, but actually I don't like "[with] d=0" much either;
"[with] d equal to zero" would be better I think, and matches the
wording in the later clause better.
....................................................................
F08/0056
Corbett reason for NO vote:
I continue to oppose this interpretation. I think the functionality
it provides is too little to be worth the risk of misuse. I have yet
to think of a case where I would want use the functionality provided.
I can easily imagine cases where the wrong variable is used in the
SOURCE= specifier and the error goes undetected.
....................................................................
F08/0057
Muxworthy comment:
It would be more in accordance with previous practice to number the
new constraint C1504a. [Corrigendum 1 uses both upper and lower case
suffices for new constraints. Presumably lower case is preferred.]
Reply from the editor:
I agree. I think we should use lower case for the suffices.
Snyder comment:
Does this need a compatibility caveat in 1.6?
....................................................................
F08/0058
Corbett reason for NO vote:
I continue to believe that removal of this restriction in Fortran 90
was deliberate. The restriction in FORTRAN 77 was intended to make
it easier to write one-pass compilers. Many such restrictions were
removed in Fortran 90. The restriction serves no purpose now.
The restriction in the FORTRAN 77 standard is in paragraph 2 of
Section 15.7.4.
Snyder comment:
Replace "program" in the first paragraph of the answer with "module".
....................................................................
F08/0059
Long comment:
The last sentence of the Answer should begin "Edits are"
instead of "An edit is". There are two edits.
....................................................................
F08/0063
Cohen comment on Corbett NO vote:
> This interpretation upends the meaning of item (5) in Clause 10.7.2.1.
> A similar argument could be made against any application of item (5).
I disagree.
F6.1 makes sense and according to item (5) will produce asterisks for
large values e.g. 1e8.
E10.2E2 makes sense and according to item (5) will produce asterisks for
large enough values e.g. 1d200.
F4.5 does not make sense. The standard does not make sense of F4.5, so
it does not say *anything*.
It would be a good idea to require F4.5 to produce 4 asterisks in the
next revision, sure looks like a wart to me.
Corbett reason for NO vote:
This interpretation upends the meaning of item (5) in Clause 10.7.2.1.
A similar argument could be made against any application of item (5).
I am surprised anyone thinks that editing under an F4.5 edit
descriptor should be permitted to produce anything other than four
asterisks. Under the proposed interpretation, I have no idea what
should be expected as a result of editing under an F4.4 edit
descriptor.
Maclaren comment:
This is a good candidate for improvement in a future revision.
....................................................................
F08/0064
Corbett comment:
There should be no "their" in the sentence
This relies on their being a difference between "no value" and
"zero-length value".
Long comment:
Perhaps the original should have been "there".
....................................................................
F08/0065
Maclaren comment:
Upon checking on what this meant, I believe that the lists in tables
14.1 and 14.2 contain some errors. Specifically, I can see no reason
for IEEE_GET_ROUNDING MODE and IEEE_GET_UNDERFLOW MODE not to be pure
(but they aren't), but I can see good reasons for IEEE_SET_FLAG and
IEEE_SET_HALTING_MODE not to be (and they are). However, even if true,
that is a matter for a future revision.
....................................................................
F08/0067
Corbett comment:
I agree that the program should not be standard conforming, and I agree
that the edit provided ensures that it is not. I do not agree with the
rationale given for the answer. Whether the invocation of SUB2 in SUB1
does or does not require the shape of A depends on the argument passing
conventions used by the processor. While all or almost all existing
Fortran processors use copy-in/copy-out to pass the array argument to
SUB2, the Fortran standard does not require a conforming processor to
use copy-in/copy-out. Other argument passing conventions exist that do
not require making a copy in this case. Those conventions do not
require the shape or size of A to be known.
Snyder comment:
To clarify the answer, it would be helpful to replace ", and
therefore the" by "because, in the absense of an explicit
interface, the corresponding dummy argument is assumed to be
nonpolymorphic, and therefore a copy consisting only of the
declared type part of the actual argument is required. The"
....................................................................
F08/0068
Long comment:
I think that the second bullets in each of the two edits is
trying to say that the dummy argument becomes associated with the part
of the actual argument (target) with the declared type of the dummy
argument. The current "declared type part of that actual argument
(target)" could be confused to refer to the declared type of the
actual argument.
....................................................................
F08/0072
Long comment:
It would be helpful to supply more explanation than just
"No." for the answer. Specification of rank is allowed for a FINAL
subroutine dummy argument. Why should corank be different?
Reply from the editor:
Because we did not intend it to do that, and it would not make any sense.
We don't need to write a treatise on language design, we just need to
answer the question. "No" conveys the entirety of "we did not intend to
do that", which is the only thing we can easily agree on. Doing anything
more would not only be difficult to craft all those language-design-
principlely words and getting agreement all the way up and down the
committees, but would delay answering the actual question and fixing the
standard.
(Actually rank specification would not have made a lot of sense either if
F2003 had had impure elemental procedures... it was merely papering over
that particular deficiency in the language.)
....................................................................
F08/0073
Cohen comment:
The note about the edit being unnecessary if F08/0059 passes should
be an instruction not to make the edit in that case.
Reid comment:
I hope we pass F08/0059 and do not make the edit in F08/0073.
....................................................................
More information about the J3
mailing list