J3/03-142r1

Date:     4-apr-2003
To:       J3
From:     Toon Moene
Subject:  Edits for 2.5, 2.6, 2.11, and 2.12(T6) of US comments

All edits herein are with respect to J3/02-007r3.

I. The edits in part I of 03-142 moved to part II of 03-171r1.

II. The edits in part II of 03-142 moved to part III of 03-171r1.

III. The following edits are suggested for the issue mentioned in
  03-107r1 section 2.5.  Note that paper 03-117 proposes incompatible
  edits; we should not pass both versions.

  (This implements exactly what 03-107r2 recommended - namely that
  BIND(C) is mandatory with enum.  I'm not 100% certain whether that
  was the literal intent or whether it was intended that the BIND(C)
  be implicit.  Either option seems at least plausible, and it is
  trivial to modify these edits either way.  It looks slightly odd to
  require explicit specification of the only option, though I can see
  that could facilitate future addition of other options.)

    [62:1] Delete this line

    [62:10] Replace "whose kind parameter is determined as follows:"
    with "type."

    [62:11] "(1) If BIND(C) is specified, the" -> "The".  Also outdent
    the whole para to the level of the normal text, and merge with the
    prevous paragraph.

    [62:19-20] Delete these 2 lines.

    [63:Note 4.63+1-4] replace the first 4 lines with
    "Example of an enumeration definition:"

    [63:Note 4.63+9-13]  Delete these 4 lines.

    [63:Note 4.63+14-17] Uncomment these 4 lines and make them a
    normal note paragraph.  (This edit isn't strictly necessary, but
    I think it improves the presentation.)

    [63:Note 4.63+17] Change "possibility" to "possible equivalent",
    and add a blank line after this line.


------------------------


IV. The following edits are suggested for the wording problems
  mentioned in 03-107r1 section 2.11.

  W8.

    This is a minor revision of an edit originally suggested
    in 02-287 (but deleted from 02-287r1).

    [399:37-38] "Within the scope of a FORALL construct, an"
                 -> "An"

    [399:38] Insert "contained" before the first "FORALL".

    [399:39] "a" -> "any of its"; "construct" -> "constructs"

  W9.

    [402:1-9] replace this para with

     "If an external or dummy procedure with an implicit interface is
      accessed via host association, then it shall have the EXTERNAL
      attribute in the host scoping unit; if it is invoked as a
      function in the inner scoping unit, its type and type parameters
      shall be established in the host scoping unit.  The type and
      type parameters of a function with the EXTERNAL attribute are
      established in a scoping unit if that scoping unit explicitly
      declares them, invokes the function, accesses the function from
      a module, or accesses the function from its host where its type
      and type parameters are established.

      If an intrinsic procedure is accessed via host association, then
      it shall be established to be intrinsic in the host scoping
      unit.  An intrinsic procedure is established to be intrinsic in
      a scoping unit if that scoping unit explicitly gives it the
      INTRINSIC attribute, invokes it as an intrinsic procedure,
      accesses it from a module, or accesses it from its host where
      it is established to be intrinsic."

    Note the following points; I mention these here because it is easy
    to get this stuff wrong (it has been the subject of multiple
    interps).  So if the above edits for this item are redone, be sure
    to consider these issues.

    1. We allow the type and type parameters of a function to be
       unknown as long as we don't invoke the function; we even
       allow it to be unknown whether it is a function or
       subroutine.

    2. The original test used the phrases "invoked as a function" and
       "used as a function".  If these mean anything different, I
       couldn't deduce the difference.

    3. We don't have to repeat the details of 249:1-5 here.  I see no
       benefit to compensate for the added complexity and
       chance for inconsistency introduced by the repetition.

    4. Don't forget about statement functions; a few of the above words
       are to avoid saying incorrect things about statement functions.
       (Statement functions can get implicitly typed without being
       invoked).

    5. Looks to me like the original text failed to cover the case
       where X is the host of Y, which is the host of Z, and things
       are established in X by any way other than X using M.  The
       above words cover this.

V. The following edits are suggested for the technical problems
  mentioned in 03-107r1 section 2.12.

  T5

    This item is described in a separate paper: 03-160.

  T6

    The following is a somewhat hurried job of minimalist edits
    for this item, but it ought to be better than what is in the
    existing draft (nothing).

    [261:13+]  Insert new paras

    "If a <proc-attr-spec> other than a <proc-language-binding-spec>
     appears, it specifies that the declared procedures or procedure
     pointers have that attribute.  These attributes are described
     in 5.1.2.  If a <proc-language-binding-spec> with NAME=
     appears, it specifies a binding label as described in 15.4.1.
     A <proc-language-binding-spec> without a NAME= is allowed,
     but is redundant with the <proc-interface> required by C1218.

     If => <null-init> appears in a <proc-decl> in a
     <procedure-declaration-stmt>, it specifies that the initial
     association status of the corresponding procedure entity is
     disassociated.  It also implies the SAVE attribute, which may
     be reaffirmed by explicit use of the SAVE attribute in the
     <procedure-declaration-stmt> or by a SAVE statement."

     (Am I correct about the proc-language-binding-spec without a
     NAME=?  It sure looks to me like it is redundant).

  T8

    This item is addressed in 03-105r1.