ISO/IEC JTC1/SC22/WG5 N2097
Result of the WG5 straw ballot on second draft Corrigendum 4
John Reid
N2096 asked this question
"Is N2095, with the references and notes removed, acceptable for
submission to SC22 for publication as Corrigendum 4 for Fortran 2008?"
The straw ballots were as follows
1) Yes
Bader, Chen, Clune, Corbett, LeAir, Long, Moene, Muxworthy, Nagle, Reid,
Snyder (11)
2) Yes, but I recommend the following changes.
Kruyt, Whitlock (2)
3) No, for the following reasons.
Cohen (1)
4) Abstain.
None.
The ballot passes, subject to J3 considering all the comments and
providing a list of changes.
Here are the comments:
Malcolm Cohen
CHANGES:
I’m sorry, but this draft corrigendum makes 9.12p5 say
“The value of an \si{internal-file-variable} ... shall not ... be
affected by data transfer caused by that statement.”
And yet, this is the ENTIRE PURPOSE of a WRITE to an internal file,
to affect the value of the internal-file-variable by means of data
transfer!
It is clear that we cannot cover everything in a single sentence,
since the requirements on input and output statements should be quite
different. More words are needed.
My vote will change back to “Yes” if all the edits from interp F08/0110
are removed. This interp needs to go back to square one.
(1) In the edit for F08/0131 (page xvi), after "A contiguous array" insert
the word "variable". This is because the sentence later says "provided the
variable ..." and this is meant to apply both to the contiguous array or the
scalar character variable.
(2) Same edit, slightly later in the sentence, change "kind and kind type
parameter" to "type and kind type parameter (if any)". This is obviously
what the interp was talking about - the edit should not be insisting that
the kind be interoperable twice. The "(if any)" is because I think this can
apply when the array is of a BIND(C) type, which has no type parameter.
(3) In the edit for F08/0127, change "is permitted to" to "can", i.e. the
replacement text should read "A free form continuation line can begin with
...". Reason: the Introduction is non-normative so we are not allowed to
have requirements here.
(4) In the edit for F08/0124, the location should be "Subclause 1.3", and
the instruction should be "After the definition of parent component
(1.3.33.2), insert a new term:", as although definitions use the same
numbering scheme as subclauses, they are not actually subclauses: see ISO
directives part 2 which says
"terms and definitions are a definitions list and not a series of
subclauses".
(5) Subclause 4.3.1.3
Change "the derived-type-def of the specified derived type" to "its
derived-type-def".
Reason: immediately prior to this we've established that we are talking
about "that derived type" (which is "the derived type [] specified in the
FUNCTION statement"); switching from "that derived type" to "the specified
derived type" implies there is some other specified derived type (which is
not the case) as well as being unnecessarily long-winded platitudinous
ponderosity. "its" is more than adequate!
(6) It does not really matter for a corrigendum, but the edit for 5.3.4
inserts a disjunction into a paragraph that already has a conjunction,
without adding a comma for disambiguation. One can deduce the parse from
the fact that it has bullet points, but it would be slightly nicer if there
were also a comma before the "and" at the end of the first bullet point. (I
will have to remember this when applying the changes to 007!)
(7) In the edit for F08/0130 at [128:15-17], in the first change use "other
than" not "apart from". This is because that is the wording we use
elsewhere (and although the difference is subtle, "apart from" does not have
quite the right connotations for this context). I note that this same
interp has the correct wording in its edit for [131:16-19](!) so we need to
be consistent.
(8) Same edit, in the editing instructions, delete the comma after
"STAT_STOPPED_IMAGE occurs", since that would produce consecutive commas in
the standard (the "so that the entire paragraph reads" bit is right).
(9) In the edit for F08/0130 at [131:16-19], the reference should be
[131:17-19] since line 16 is unchanged.
(10) Same edit, in the editing instructions, delete the comma after
"STAT_STOPPED_IMAGE occurs".
(11) In the edit for F08/0104 at [150:28+], the editing instructions should
say "item (10)" not "bullet item (10)" since it is not a bullet item, and
should say "insert a new item" not "insert a new bullet", for the same
reason.
(12) Same edit, item "(nn)" should be "(10a)" in accordance with our usual
conventions, so as to be consistent with many other interps.
(13) In the edit for F08/0126 at [151:7-8], "coarray bound" should be
"cobound", twice (we do not have to say "coarray cobound" as that is
unnecessarily redundant) actually it would be even clearer to without
repeating an indefinite article in the first place, i.e. the edit should be
"a type parameter or an array bound"
->"a type parameter, array bound, or cobound"
"the type parameter or array bound"
->"the type parameter, array bound, or cobound".
(14) Actually, that paragraph also needs the edit
"\si{specification-part}" -> "scoping unit", thrice, but that's probably
beyond the bounds of what we can safely change at this point.
(15) In the edit for F08/0104 at [152:7-8], in the editing instructions,
delete the word "bullet" (it is not a bullet item).
(16) In the edit for F08/0140 at [153:25-28], the final bullet does not
need any condition, it could just simply be "each deferred length
parameter of the variable...", i.e. the edit could be described as
After "coindexed object," delete "the variable",
before each "shall not" insert "the variable",
before "shall have" insert "of the variable".
(17) In the edit for F08/0144 at [178:18+], the problem here is that
this is inserting stuff in the middle of the changes from another
Corrigendum, which in fact has already deleted the bullet point that
this is trying to insert stuff after! This would be better located
at [178:16+], and change “at the end of the bullet list” to
“after the bullet item beginning ‘An input/output statement’.
(18) In the edit for F08/0134 at [190:5+], the constraint is properly
worded so that the restriction to the syntax rule “(R859)” is
unnecessary. It is also harmless.
(19) I note that some of the requirements are expressed in a fairly
woolly way. E.g. the ones added by interp F08/0113 should be worded so
that it is more obvious that it is the lock-variable and stat-variable
in the same (LOCK or UNLOCK) statement, not (e.g.) the lock-variable
from a LOCK statement and a stat-variable from a DEALLOCATE statement.
Yes, it’s clear from context that that is what is being meant, so I
think this is not really a problem for the corrigendum per se
(especially since similar woolly wording already appears elsewhere),
but I think that when I apply the corrigendum to the 007 I should
try to reword them.
(20) The edits for F08/0110 need to be pulled (see previous message),
but anyway, the edit instructions refer to the “fifth paragraph,
provided by Technical Corrigendum 2”, but in fact the fifth paragraph
was NOT “provided” by corrigendum 2, but merely edited by it. So
those instructions should be “fifth paragraph, as edited by Technical
Corrigendum 2” (or “after applying the changes in ...”, which phrasing
you used elsewhere).
(21) In the edit for F08/0132 at [281:25-28], I think it would be
better to omit the noninitial indefinite articles in the first part
of the edit, i.e. it would be better as
“or a dummy procedure” –> “, dummy procedure, or procedure pointer”.
(22) Same edit, the editing instructions say to make a double comma,
as the comma following the “; otherwise” is not deleted but it says
to insert one at the end of the insertion, thus producing “...procedure
pointer,, it...”. Delete the comma at the end of the last insertion.
(23) Same edit, I find “is not a DP and is not a PP” slightly clumsy.
Either “is not a DP or PP” or “is neither a DP nor a PP” would be
better – I think I prefer “is not a DP or PP”.
(24) In the edits for F08/0117 at [300:14] and [300:22], these result
in the unfortunate construction “other than an array section with a
vector subscript or coindexed object”. Yes, one can eventually work
out that an array section cannot “have” a coindexed object, and that
therefore the disjunction applies to the “other than”, but it certainly
sounds confusingly weird. Better to make that “other than a coindexed
object or an array section with a vector subscript”, i.e. the edits
should be after “target other than” insert “a coindexed object or”
(twice).
(25) In the edit for F08/0109 at [399:17], change “LOCK TYPE” to
“LOCK_TYPE” (space to underscore).
(26) It does not matter for the Corrigendum, but I note that the effect
of the edit for F08/0116 at [436:16-19] will have dashes rather than
bullets for the nested bullet list.
(27) Similarly the Corrigendum is ok, but I note the edit for F08/0120
at [440:4] could be slightly more simply described as: after “named
constants,” insert “named procedure pointers,”.
____________________________________________________________________
Robert Corbett
I think Subclause 9.12 needs further revision, but the proposed edits
do not make the subclause worse.
____________________________________________________________________
Erik Kruyt
CHANGES:
Subclause 11.2.3
In constraint C1113, after "shall be the name of a nonintrinsic module"
insert "that declares a separate module procedure".
Change to:
In constraint C1113, after "shall be the name of a nonintrinsic module"
insert "that declares a separate module procedure of which the separate
module procedure is not present".
Reason: If the implementation of the separate module procedure is in
the module there is also no need for a submodule.
[Malcolm Cohen says "This would be a technical change to the result
of interpretation F08/0142. I do not think we can do that at this time.]
_______________________________________________________________________
Bill Long
Although if Malcolm has wording improvements in some of the edits, I
would not be opposed to those changes.
_____________________________________________________________________
Van Snyder
The opening quote mark in the replacement at [281:25-28] is actually a
closing quote mark.
_____________________________________________________________________
Stan Whitlock
* [6:7+] should "parent component" be bold?
* [150:28+] and [152:7-8] add transformational functions from certain
intrinsic modules to constant and specification expressions,
respectively. Should this be mentioned in the Introduction [xv]
as new to F2008?
* [152:7-8] should "IEEE_ARITHMETIC" be followed by an xref "(14)" like
in [150:28+]?
* [194:6-] and [195:2-] inconsistently precede {or not} terms
, , and with "the".
Should these edits at least be consistent?
* [243:6-7] Note 9.64a says "data object" when the interp edit says
"variable". I could not find an interp ballot that made this
change although it seems reasonable. Which term should be used in
this note?
[Robert Corbett says: This change was made in response to my complaint
about the wording in the first ballot.
In particular, the same restriction is needed for named constants as is
needed for variables. The term "data object" covers both cases.]