(j3.2006) (SC22WG5.5656) [ukfortran] Straw ballot on second draft corrigendum4

[Cohen Malcolm]

This is an interim vote.  I might have other changes to suggest later (I am 
only 1/4 of the way through...).

>Please answer the following question "Is N2095, with the references and
>notes removed, acceptable for submission to SC22 for publication as
>Corrigendum 4 for Fortran 2008?" in one of these ways.
>
>1) Yes.
>2) Yes, but I recommend the following changes.

Yes, but I recommend the following changes.

>3) No, for the following reasons.
>4) Abstain.

CHANGES:
(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 <B>parent component</B> 
(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 <I>derived-type-def</I> of the specified derived type" to "its 
<I>derived-type-def</I>".
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!)

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.