J3/15-189
To: J3
From: Malcolm Cohen
Subject: Editorial fixes for 15-007r1
Date: 2015 July 23

1. Introduction

This paper contains editorial improvements and wording fixes for 15-007r1.


2. Discussion

(a) Uses of LOCK_TYPE do not always mention that the LOCK_TYPE in question
    is the one from ISO_FORTRAN_ENV; canonically it is
        LOCK_TYPE (\ref{D13:LOCK_TYPE}) from \theimod{ISO_FORTRAN_ENV},
    where \theimod{X} expands to a hyperlinked "the intrinsic module X",
    or, without a cross-reference,
        \reftype*{LOCK_TYPE} from \theimod{ISO_FORTRAN_ENV}

(b) Uses of type C_PTR do not always mention that the C_PTR in question is
    the one from the intrinsic module ISO_C_BINDING.

(c) Uses of type C_FUNPTR do not always mention etc.

(d) 8.5.6 LOCK and UNLOCK statements, p1, is just wrong.
    There is No Guarantee Whatsoever that LOCK_TYPE() is a reference to
    the structure constructor for LOCK_TYPE in ISO_FORTRAN_ENV, since it
    can be generically overridden to be a function reference; also, since
    LOCK_TYPE is accessed by use association, LOCK_TYPE() might be
    completely unrelated even if it were a structure constructor.
    Also, we should not be using "equal" with respect to derived types
    since they have no intrinsic concept of value equality.

(e) 13.9.2.16 LOCK_TYPE is badly worded.
    It uses the term "initial value", but a variable of type LOCK_TYPE is
    not required to have the SAVE attribute; for example, it can be a
    subobject of an ALLOCATABLE coarray.  TSuch a variable does not have
    any initial value, thus the standard does not establish an
    interpretation for unsaved lock variables!  This should be repaired.

(f) Unhelpful uninformative misleading remark
        "in which case the copy is regarded as undefined"
    immediately following the normative text which states
        "the variable becomes undefined".
    It would not be unusual for a naive reader to understand
        "is regarded as"
    to mean "processor dependent".  This remark must go.

(g) In a couple of places we say "cannot distinguish" between positive and
    negative real zero, but such distinguishing is not actually physically
    impossible so we should say "does not distinguish".  Similarly, in
    several places we say "can distinguish" when what we mean is "does
    distinguish" (or more concisely, "distinguishes").

(h) A mistake in 15-137r1 accidentally permitted a statement function
    definition to appear in a BLOCK construct, so long as it is followed
    by an ordinary declarative, viz <specification-construct>.  The
    constraint against these appearing in BLOCK needs to be reinstated.

(i) Paragraphs 4 and 5 of 4.2 Type parameters are largely redundant, badly
    worded, and badly organized.  Use of "may" in text that does not
    contain requirements is bad wording (ought to be "can").
    Some of this is useful as redundant introductory blather, but most
    of it should go.  The text in subclauses of 4.4 and 4.5 already
    specify this in greater detail and arguably greater clarity.
    NOTE 4.1p1 refers to stuff in p6 so should be a note by itself,
    preferably at the end of the subclause entirely.  NOTE 4.1p2 is
    ONLY about derived-type parameters so ought to be in 4.5.3, or
    it could be deleted entirely.

(j) In the Fortran 77 compatibility we say
        "if the processor [distinguishes] between positive and negative
         real zero, [the output is different]"
    which since F77 did not permit the processor to distinguish between
    positive and negative real zero, boils down to
        "if the processor does not conform to F77, it does not conform to
         F77".
    That is, the incompatibility is the distinguishing of negative real
    zero, not the output of SIGN.

    Similarly for Fortran 90 compatibility, except there we just say
    directly that the result of SIGN differs, which will be news to those
    vendors whose compilers do not distinguish between positive and
    negative real zero.


3. Edits to 15-007r1

These edits use \theimod{X} for "the intrinsic module X".

NOTE TO EDITOR: Remember to use \reftype* for all the type names.

[26:10] 1.6.5 Fortran 95 compatibility, p3, 3rd bullet,
        "can distinguish" -> "distinguishes".
{(g).}

[26:29] 1.6.6 Fortran 90 compatibility, p5, first bullet,
        Before "the result" insert
          "if a processor distinguishes between positive and negative
           real zero,"
        after "function SIGN" delete "("
        after "zero" delete ")".
This makes that bullet point read:
  "- if a processor distinguishes between positive and negative real
     zero, the result value of the intrinsic function SIGN when the second
     argument is a negative real zero;".
{(j).}

[27:14-15] 1.6.7 Fortran 77 compatibility, last bullet, replace with
  "Fortran 77 did not permit a processor to distinguish between positive
   and negative real zero; if a processor does so distinguish, the
   result will differ for the intrinsic function SIGN when the second
   argument is negative real zero, and formatted output of negative real
   zero will be different."
{(g,j).  The new wording is a bit clunky...}

[52:6] 4.2 Type parameters, p3, append new sentence
       "A kind type parameter participates in generic resolution
        (12.5.5.2), but a length type parameter does not."
{(i).  This info better fits here rather than p4/p5.  Ref is to
 "Resolving procedure references to names established to be generic".}

[52:7-9] 4.2 Type parameters, p4, Rewrite as follows:
  "Each intrinsic type has a kind type parameter named KIND.  The
   intrinsic character type has a length type parameter named LEN.
   A derived type can have type parameters."
{(i).  All this is described fully under each type, so here we should just
 stick to the point, which is that they have type parameters, and not what
 they are used for.}

[52:10-12] Same subclause, p5, delete entire paragraph.
{(i).  The interesting bits are already inserted into p3/p4 above.}

[52:9+1-9,12+1-5] Same subclause, Delete notes 4.1 and 4.2.
{(i).  They are out of place here.}

[53:4+] Same subclause, at the end,
        Insert new note containing the first paragraph of NOTE 4.1 as it
        was, and the second paragraph being the contents of NOTE 4.2 as
        it was.
{(i).  Reinstate the more relevant parts of the notes.}

OPTIONAL:
[67:20+] 4.5.3.1 Type parameter definition statement, before NOTE 4.23,
         Insert new NOTE containing the first sentence of the second
         paragraph of the old NOTE 4.1, inserting a comma after "that is".
         The new note will therefore read
  "NOTE 4.22a
   A type parameter of a derived type can be specified to be a kind type
   parameter in order to allow generic resolution based on the parameter;
   that is, to allow a single generic to include two specific procedures
   that have interfaces distinguished only by the value of a kind type
   parameter of a dummy argument."
{(i).  Move this to where it belongs.  The rest of NOTE 4.1
   "All generic references are resolvable at compile time."
 is not interesting and not relevant to clause 4 Types!
 I have marked this down as optional as this is programme design advice,
 unnecessary in a language standard.}

reinstate notes 4.1 and 4.2 as a single
        combined note, with note 4.2 becoming the 3rd paragraph of the
        result.
{(i).  Optional because there is a lot of junk in these notes that ought
 not to be even in this subclause at all, e.g. NOTE 4.1p2 ought to be in
 4.5.3 if we want to say it.

[69:6] 4.5.4.1 Component definition statement, C448,
       Between "C_PTR or C_FUNPTR" and "(15.3.3)"
       insert "from \theimod{ISO_C_BINDING}".
{(b,c).  Yes the reader could follow the reference to work out that is
 what we meant, but we should state it explicitly.}

[95:21] 5.5.6.1 General, C524,
       Between "C_PTR or C_FUNPTR" and "(15.3.3)"
       insert "from \theimod{ISO_C_BINDING}".
{(b,c).}

[113:18-19] 5.6.15 TARGET statement, R560 <target-decl>,
  Remove excess vertical space in between the 2 lines of this syntax rule.

[123:11] 6.4.2 Structure components, C616,
       Between "C_PTR or C_FUNPTR" and "(15.3.3)"
       insert "from \theimod{ISO_C_BINDING}".
{(b,c).}

[131:8] 6.7.1.1 Form of the ALLOCATE statement, C642,
  Replace whole constraint
    "type-spec shall not specify the type C_PTR or C_FUNPTR if an
     allocate-object is a coarray."
  with
     "If an <allocate-object> is a coarray, <type-spec> shall not specify
      the type C_PTR or C_FUNPTR from \theimod{ISO_C_BINDING}.".
{(b,c).}

[131:9] same subclause, C643,
        "C_PTR, C_FUNPTR, or LOCK_TYPE"
        -> "C_PTR or C_FUNPTR from \theimod{ISO_C_BINDING},
            or LOCK_TYPE from \theimod{ISO_FORTRAN_ENV}"
{(a,b,c).}

OPTIONAL:
[131:10] same subclause, same constraint,
         "LOCK_TYPE" -> "LOCK_TYPE from \theimod{ISO_FORTRAN_ENV}".
{(a).  Given this is later in the same sentence I think it is obvious that
 this is the LOCK_TYPE that is being referred to, but if anyone wants it
 to be made completely explicit I have no objection... as long as it
 becomes equally explicit everywhere else!}

[131:20] same subclause, p4,
         "C_PTR, C_FUNPTR, or LOCK_TYPE"
         ->"C_PTR or C_FUNPTR from \theimod{ISO_C_BINDING}, or LOCK_TYPE
            from \theimod{ISO_FORTRAN_ENV}"
{(a,b,c)}

OPTIONAL:
[131:20] same subclause, same paragraph, same sentence,
         "is LOCK_TYPE" -> "is LOCK_TYPE from \theimod{ISO_FORTRAN_ENV}".
{(a).  See [131:10].}

[160:6] 7.2.1.3 Interpretation of intrinsic assignments, p12,
        After "For an intrinsic assignment of the type C_PTR or C_FUNPTR,"
        insert "from \theimod{ISO_C_BINDING}".
{(b,c).}

[160:7+4-5] Same subclause, NOTE 7.40,
            Delete ", in which case the copy is regarded as undefined".
{(f).  with prejudice.}

[174:2] 8.1.4 BLOCK construct, C807 "The <block-specification-part>...",
        After "OPTIONAL,"
        insert "\obs{statement function,}".
{(h).}

[195:8] 8.5.6 LOCK and UNLOCK statements, C852,
        After "LOCK_TYPE (ref)"
        insert "from \theimod{ISO_FORTRAN_ENV}".
{(a).  Yes the user could follow the reference and thereby discover that
 this is the one in ISO_FORTRAN_ENV being referred to, but why make him
 do that work?}

[195:9] same subclause, para 1, replace first sentence "A ... ( )." with
  "A lock variable is unlocked if and only if the value of each component
   is the same as its default value.".
{(d).  I should note that this is partially redundant with the definition
 of LOCK_TYPE in clause 13, so there is scope for rewording.}

[247:3] 10.1 Format specifications, p1,
        Between "used in conjunction with" and "data transfer statement"
        insert "a".
{Missing article.}

[338:17] 13.8.18 ATAN2, p5 Result Value,
         "cannot distinguish" -> "does not distinguish".
{(g).}

[375:27] 13.8.109 LOG, p5 Result Value,
         "cannot distinguish" -> "does not distinguish".
{(g).}

[414:14] 13.9.2.16 LOCK_TYPE, p2,
         "initial value" -> "default value".
{(e).}

[473:14,20,21] 15.5.5.7 The CFI_section function, p2 Formal Parameters,
               result item,
               "\cf{stride}" -> "\cf{strides}" thrice,
  i.e. "\cf{upper_bounds}, and \cf{stride}"
       ->"\cf{upper_bounds}, and \cf{strides}",
       "if \cf{stride}" -> "if \cf{strides}",
       "\cf{stride}[$i$]" -> "\cf{strides}[$i$]".
{The formal parameter is called "strides" not "stride".}

[497:41] 16.6.6 Events that cause variables to become undefined,
         item (3)(c) "When execution of an instance of a subprogram...",
         After "of type C_PTR"
         insert "from \theimod{ISO_C_BINDING}".
{(b).}

[499:8] Same subclause, item (19) "When a variable with the TARGET...",
        After "of type C_PTR"
        insert "from \theimod{ISO_C_BINDING}".
{(b).}

[499:10] Same subclause, item (20) "When a pointer is deallocated...",
         After "of type C_PTR"
         insert "from \theimod{ISO_C_BINDING}".
{(b).}

[499:13] Same subclause item (21) "Execution of the allocation trans...",
         After "of type C_PTR"
         insert "from \theimod{ISO_C_BINDING}".
{(b).}

[499:17-18] Same subclause, item (22) "When a BLOCK construct complet...",
            After "of type C_PTR"
            insert "from \theimod{ISO_C_BINDING},",
            after "BLOCK construct",
            insert a comma.
{(b).}

[499:19] Same subclause, item (23) "When execution of the host insta...",
         After "of type C_FUNPTR"
         insert "from \theimod{ISO_C_BINDING}".
{(c).}

[499:21] Same subclause, item (24) "Execution of an intrinsic assign...",
         After "of the type C_PTR of C_FUNPTR"
         insert "from \theimod{ISO_C_BINDING}".
{(b,c).}

===END===