Subject: Responses to Public Comment #11 (Hirchert)   J3/02-314r1
From: Kurt W. Hirchert                  (Meeting 163) 14 Nov 2002

=========
Responses
=========

1.  J3 will propose changes to WG5 to address this editorial problem.

2.  The omission was unintentional.  J3 will propose to WG5 that such
    a cross reference be included.

3.  J3 believes that this is too large a change to make at this point
    solely to improve readability.  However, it will keep this
    suggestion in mind should this text need to be changed for
    technical reasons.

4.  J3 agrees that there is a problem here and will recommend to WG5
    that it be fixed.  However, that fix may differ from the one
    you propose.

5.  In view of the relative magnitudes of the possible benefit of
    your suggestion and its potential to delay the availability of
    this revision, J3 believes it should not be pursued at this
    time.  It might be pursued in the context of a future revision.

    [This response should also be used for items 9, 12-15, 17-19,
    21-22, and 25-28.]

6.  J3 does not believe that there is a problem with the current
    semantics of IMPORT and is recommending no change in this area.

7.  J3 will recommend that this change be made.

    [This response should also be used for item 11.]

8.  J3 is recommending that NONKIND be changed to EXTENT.

10. J3 feels that the name C_F_POINTER is consistent with the
    naming conventions generally used in the C interoperability
    facility and is recommending no change in this regard.

16. J3 is not recommending the addition of SIZEOF at this time.

20. J3 is preparing recommendations for a reinstatement of deferred
    procedure bindings consistent with your expressed concerns.

23. J3 does not believe that connecting functions to the structure
    constructor syntax offers a significant benefit over the direct
    use of functions to construct derived-type values and is
    recommending no change in this area.

24. J3 does not believe it would be appropriate to significantly
    change the approach to C interoperability used in the draft.


===============
Edits and Notes
===============

1.  382:17, 383:11, 384:1  Change these lines to (level 4) section
    headers.

2.  {* Just make sure this gets on the list of things to do. *}

4.  {* Edits will have to developed (by Kurt) between meetings.
    He will circulate drafts of them as soon as possible after
    this meeting. *}

7.  275:12-14  Change to
R1224 <function-stmt> is [<prefix>] FUNCTION <function-name> &
                         & ([<dummy-arg-name-list>]) [<suffix>]

    275:38+  Insert
R1228a <suffix> is <proc-language-binding-spec> [RESULT(<result-name>)]
                or RESULT(<result-name>) [<proc-language-binding-spec>]
{* For only two items, the above approach to the BNF seems simplest.
If there were more, I would suggest the approach used for <prefix>. *}

    277:8-9  Change to
R1231 <subroutine-stmt> is <prefix> SUBROUTINE <subroutine-name> &
              & [([<dummy-arg-list>])[<proc-language-binding-spec>]]

    278:31-35  Change to
R1234 <entry-stmt> is ENTRY <entry-name> [([<dummy-arg-list>])[<suffix>]]
{* Yes, this really replaces _both_ of the existing alternatives. *}

11. 188:8+  Insert
C929a (R914) If <default-char-expr> is an initialization expression
      (7.1.7), the leading part of its value shall be a valid
      format specification (10.1.1).
{* Compare this to the dynamic requirement in 10.1.2. *}

20. {* This is the work Aleksandar is doing. *}

                              - end -