(j3.2006) (SC22WG5.5172) Draft result of ballot on Corrigendum 3
John Reid
John.Reid
Tue Dec 24 11:03:55 EST 2013
WG5,
Here is a second draft result of the ballot on Corrigendum 3.
I have added David's vote (overlooked in first version) and Malcolm has
asked to change his vote (to accord with his recent emails). After
consulting the Editorial group, my conclusion is that the corrigendum be
accepted after Malcolm's changes have been included. This has 8 yes
votes and one no vote.
David, please will you make these changes and look at the minor changes
that people have suggested?
Happy Christmas,
John.
-------------- next part --------------
ISO/IEC JTC1/SC22/WG5 N2001-2
Result of the WG5 letter ballot on draft Corrigendum 3
John Reid
N1998 asked this question
Please answer the following question "Is N1995, with the references and
notes removed, acceptable for submission to SC22 for publication as
Corrigendum 3 for Fortran 2008?" in one of these ways.
1) Yes.
2) Yes, but I recommend the following changes.
3) No, for the following reasons.
4) Abstain.
Email discussion led to the conclusion that the edits in F08/0086 were
flawed. A revised version was prepared by Malcolm Cohen and is appended
to this paper. All votes referenced this paper.
The numbers of answers in each category were:
1 for 1) Yes (Corbett).
1 for 2) Yes, but I recommend the following changes (Snyder)
7 for 3) No, for the following reasons (Bader, Cohen, Long, Moene,
Muxworthy, Reid, Whitlock)
0 for 4) Abstain
The ballot has failed, but six of those who voted "No" said they would
change their vote to "Yes" if the corrigendum is revised to accord with
the edits in Malcolm's paper, or words to this effect. I have consulted
the editorial subgroup, who recommend that the Corrigendum be accepted
after Malcolm's changes have been made. This has the approval of 8 of
the 9 people voting. I will ask David to make these changes and the
minor changes requested in the vote. After the editorial group has
checked the revised corrigendum, I will send it to SC22 for publication.
Here are the responses in detail:
Reinhold Bader
I vote yes, provided the corrections for F08/0086 detailed in the latest
version of mjc002.txt are applied.
_______________________________________________________________________
Malcolm Cohen
Yes, provided the edits for f08/f0086 from N1987 are replaced by those
from mjc002.txt distributed on 13 December.
_______________________________________________________________________
Robert Corbett
My vote is 1) yes.
The edits for implied-shape arrays, even as modified,
are at best complicated and confusing. My complaint
is with the edits not with the corresponding
interpretation, which I think is correct. I accept
that the latest proposed edits are probably the best
we shall get for the Corrigendum. I hope we can do
better in the next revision of the standard.
As I pointed out in my ballots on the interpretations,
the same conditions that led to Subclause 7.1.11 apply
not only to the function PRESENT, but also to
ALLOCATED and ASSOCIATED.
I continue to disagree with the edits proposed for
Subclause 14.3, but I accept that I lost the vote in
committee and on the subsequent ballots.
_______________________________________________________________________
Bill Long
Minor typos in the citations: [24:14] should be [24:13]; [24:15]
should be [24:15-16].
Typo in the actual official text: In the instruction line for the edit
at [459:17+] remove the space between "2.3.5" and ")".
Reason for No vote:
---------------------------
I agree with Malcolm's original comment that Interp f08/0086 should be
failed and restarted. I'm not happy with the proposed last-minute text
file of changes for these reasons:
1) A main reason for having a vote like this is to agree (or not) on the
exact form of the PDF file form of the Corrigendum - this is basically
an "FCD" vote. That purpose is subverted here because the proposers of
this path have not supplied the PDF form of their replacements.
2) Another goal of a final vote like this is to reflect on whether we
have made a technical mistake. The complexity of the changes proposed
for f08/0086, and the problems getting them "right" convince me that we
chose the wrong answer for the interp. The alternate answer would
result in a trivial, single edit in the standard, and would prohibit
only code like that in the interp example that is confusing at best and
would never be allowed by any reasonable coding style guide. The place
to have this discussion is in the process of restarting the interp.
I would change my vote to YES if the minor corrections above are made
and the edits for f08/0086 are deleted.
_______________________________________________________________________
Toon Moene
My vote is yes, after Malcolm's revised edits for F08/0086 are included.
_______________________________________________________________________
David Muxworthy
2) Yes, provided the edits for f08/f0086 from N1987 are replaced by those
from mjc002.txt distributed on 13 December.
_______________________________________________________________________
John Reid
3) No, for the following reasons.
F08/0086 should be revised to the new version from Malcolm Cohen that
is attached.
I will change my vote to yes if the corrigendum is changed accordingly
or if the edits from F08/0086 are removed.
_______________________________________________________________________
Van Snyder
Yes, but:
In the edit for [94:10] the "i" in "implied-shape-spec" should be italic
instead of upright.
[96:28] says "The rank of an implied-shape array is the number of
<implied-shape-spec>s in the <implied-shape-spec-list>." The syntax
term <implied-shape-spec-list> no longer exists. This sentence is not
changed by the corrigendum or interp f08/0086. The sentence needs to be
changed to something like "The rank of an implied-shape array is the
number of asterisks in the <implied-shape-spec>". If this needs to go
back through the interp process, my vote must unfortunately be "no".
The edit for [158:19-20] only applies to [158:19]. This doesn't matter
for the ISO-published corrigendum, which doesn't have [page:line]
references.
(Later) I approve the revised interpretation.
_______________________________________________________________________
Stan Whitlock
I vote Yes, provided the edits for f08/f0086 from N1987 are replaced by
those from mjc002.txt distributed on 13 December.
----------------------------------------------------------------------
NUMBER: F08/0086
TITLE: Implied-shape and separate PARAMETER statement
KEYWORDS: Implied-shape, PARAMETER
DEFECT TYPE: Erratum
STATUS: Unknown
QUESTION:
Q1. Consider
Program test1
Character(*) a,b(*)
Dimension c(*)
Parameter (a='123', b=['1','2','3'])
Character(*),Parameter :: c = [ '44','55','66' ]
Print *,a,b,c
End
The definition of the assumed-length character named constant A
conforms to Fortran 77 to Fortran 2008. However, the definition of
the implied-shape named constant B appears not to conform to Fortran
2008, as the standard says in 5.4.11p2
"A named array constant defined by a PARAMETER statement shall have
its shape specified in a prior specification statement."
On the other hand, the named constant C does not have such a
requirement, so its definition would appear to be conforming.
This apparent requirement on the named constant B would thus appear to
be inconsistent with those on the named constant C, as well as
inconsistent with the way that assumed length works, and with the
general principle of allowing attributes to be specified either in a
single type declaration statement or with separate specification
statements.
Is the program intended to conform to the Fortran standard?
Q2. Consider
Subroutine test2(a)
Real,Dimension(*) :: a,c
Parameter (c = [ 45.6 ])
a(:size(c)) = c
End Subroutine
The <array-spec> in the type declaration statement is ambiguous; if it
is an <implied-shape-spec> then the declaration of A as an
assumed-size array is erroneous, but if it is an <assumed-size-spec>
then the declaration of C as an implied-shape array is erroneous.
Is this program-unit intended to be standard-conforming?
ANSWER:
A1. Yes, the program was intended to conform to the Fortran standard.
An edit is provided to modify the requirement for prior
specification so as to allow this case.
A2. Yes, the program is intended to conform to the Fortran standard.
An edit is provided to add syntax to permit this unambiguously.
EDITS to 10-007r1:
[94:10] 5.3.8.1, R515,
Change "<implied-shape-spec-list>" to "<implied-shape-spec>".
{This will be the unambiguous implied-shape syntax.}
[94:10+] Insert new production
"<<or>> <implied-shape-or-assumed-size-spec>".
{This will be the otherwise-ambiguous syntax.}
[95:32] 5.3.8.5p1
Replace sentence
"An assumed-size array is declared with an <assumed-size-spec>."
with
"A dummy argument is declared to be an assumed-size array by an
<assumed-size-spec> or an <implied-shape-or-assumed-size-spec>."
{Now two ways of declaring assumed size.}
[95:33-] Insert new BNF term
"R520a <assumed-implied-spec> <<is>> [ <lower-bound> : ] *"
[95:33] R521 <assumed-size-spec>, after "<<is>>"
Replace entire RHS
"[ <explicit-shape-spec>, ]... [ <lower-bound> : ] *"
with
"<explicit-shape-spec-list>, <assumed-implied-spec>"
{The unambiguous case has a list of <explicit-shape-spec>s.}
[95:37+] Insert new BNF rules and constraint
"R521a <implied-shape-or-assumed-size-spec> <<is>>
<assumed-implied-spec>
C534a An object whose array bounds are specified by an
<implied-shape-or-assumed-size-spec> shall be a dummy data
object or a named constant."
{The otherwise-ambiguous case. Note careful wording.}
[96:24-25] 5.3.8.6p1
Replace sentence
"An implied-shape array is declared... <implied-shape-spec-list>."
with
"A named constant is declared to be an implied-shape array with an
<array-spec> that is an <implied-shape-or-assumed-size-spec> or
an <implied-shape-spec>."
{Now two ways of declaring implied shape.}
[96:26] R522,
Replace right-hand-side (after "<<is>>")
"[ <lower-bound> : ] *"
with
"<assumed-implied-spec>, <assumed-implied-spec-list>".
{This is now the unambiguously implied-shape spec.}
[96:28] p2,
Change "<implied-shape-spec>s" -> "<assumed-implied-spec>s"
and "the <implied-shape-spec-list>" -> "its <array-spec>",
making the entire paragraph read:
"The rank of an implied-shape array is the number of
<assumed-implied-spec>s in its <array-spec>."
{Change rank determination to accord with new syntax term.}
[107:11] 5.4.11p1 "shape" -> "rank".
{In the PARAMETER statement, only require the rank to be specified in
a prior specification statement.}
NOTE for future investigation:
The current wording of C533 is slightly defective, as it does not
clearly prohibit "REAL,DIMENSION(*) :: dummy,nondummy", seeing as
how that does indeed declare "the array bounds of a dummy data
object". C533 should probably be reworded similarly to C534a.
SUBMITTED BY: Bill Long
HISTORY: 12-191 m199 F08/0086 submitted - revised by Malcolm
Cohen - passed by J3 meeting
13-237 m200 Failed letter ballot
13-235 m200 Revised with straw votes
13-235r1 m200 Passed by J3 meeting
13-262 m201 Passed as amended by J3 letter ballot #28
13-255r1
N1990 m202 Passed by WG5 ballot N1988/n1987
something ???? Revised edits from draft corrigendum ballot
----------------------------------------------------------------------
More information about the J3
mailing list