J3/97-231

attachment

J3/97-221r1

                                                      J3/97-221r1

Date:	  14 August 1997
To:	  Coco Editor and WG5
From:	  J3
Subject:  Review of WG5-N1301 (Draft Part 3: Conditional Compilation in Fortran)

J3 finds no significant changes required in the draft, but does recommend the
following changes:

 1. Section 3.2.2, add to end of first sentence, "that is not a comment line".
    Reason:  We believe the intent is that coco source form rules mimic the free
    source form rules in Part I, and without this addition, it is not clear that
    the following is permitted:

	?? IF (DEVELOPING) &
	??
	?? & THEN

 2. Note 3.3, change "(Section 7)" to "(section 7)".  Reason: Consistency
 3. Section 3.2.3, 2nd paragraph, change to, "A coco directive shall not have
    more than the number of continuation lines permitted for free source form in
    Part I.  Reason:  There will be one fewer incompatibility when Fortran 2000
    succeeds Fortran 95.
 4. Section 4, 1st sentence,  change to, "A named coco data object is a
    constant or is a variable."  Reason: This section is not dealing with
    literal constants.
 5. Sections 4-9:  The same form should be used for constraints as is used in
    Part 1, i.e., lines after the first should be indented.
 6. Rule CCR502, change "name" to ""
 7. Note 5.2, 1st sentence, change, "...by the general form in 5.2," to "...by
    the general form in section 5.2,".  Reason: avoid confusion with Note 5.2
    and Table 5.2 that appear in close proximity.
 8. Section 9, 1st sentence following list item (4), change to, "The mechanism
    for...".
 9. Section 9, 1st constraint following rule CCR902, change to, "A named
    constant declared in the  shall be declared as a constant
    with the same type and value in an executed coco directive in the coco
    program."
10. Section 9, paragraph following Note 9.1, J3 recommends copying the lines
    of the coco SET file at the end of the coco output.
11. J3 notes that the program in Note 9.3 has no loop exit and suggests it be
    terminated gracefully - preferably with the use of an IOSTAT specifier.