J3/97-231
To: Miles Ellis, Convenor, SC22/WG5
From: Jerry Wagener, Chair, J3 (WG5 primary development body)
Subject: J3 responses to WG5 Vienna resolutions
Three of the July'97 WG5 resolutions (WG5-N1290), V4 (C interoperability), V7 (conditional compilation), and V8 (interval arithmetic), make requests of the primary development body. This document (J3/97-231) constitutes J3's responses to those three resolutions.
V4 requests J3 to assume responsibility for the Fortran 2000 requirement on C interoperability. J3 has approved document J3/97-219, attached, accepting this responsibility, will add C interoperability as R.9 of the J3 workplan for Fortran 2000 (J3/97-010), and will begin work on this item immediately. Note that J3 will not process this work as a technical report.
V7 requests J3 to review the draft Part 3 on conditional compilation (WG5-1301). J3 has approved document J3/97-221r1, attached, as the requested review.
V8 requests J3 to not consider certain ways of incorporating interval arithmetic into Fortran 2000 and gives J3 added flexibility otherwise with respect to this requirement. J3 has encountered deficiencies in Fortran 95 for each of the possible development approaches for this requirement, and now believes that considerable work is required to repair these deficiencies before interval arithmetic can be incorporated well into Fortran. This could impact the Fortran 2000 schedule.
Since there appears to be no vendor commitment to the interval arithmetic requirement at this time, J3 recommends that for Fortran 2000 this requirement be limited to repairing the related deficiencies in the base language. Interval arithmetic could then be more effectively added in a future revision, when there is a better base language and more vendor support. J3 has approved document J3/97-228, attached, which supplies more details, as do a number of other papers from the Aug'97 J3 meeting. The J3 resources available for this requirement will focus solely on repairing those deficiencies, beginning immediately, and J3 will suspend work on interval arithmetic per se. Please let me know immediately if this is not acceptable to WG5, because in that event we have a serious resource and schedule problem.
J3/97-219
J3 accepts this responsibility, on the condition that J3 be allowed to do the work as a "firm requirement" for Fortran 2000 (an "R" item in the J3 workplan) and not in its current form as a technical report.
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.
J3/97-228
Rationale: After considerable technical effort over the past two years, J3 is forced to conclude that (1) standardizing interval arithmetic is premature and (2) there are non-trivial deficiencies in the base Fortran standard for implementing interval arithmetic well.
As for the first point, there currently are no commercial Fortran implementations of interval arithmetic, nor does there appear to be any producer of Fortran implementations that favors standardizing interval arithmetic at this time. Moreover, interval arithmetic and its incorporation into Fortran has been somewhat of a moving target; indeed, since J3 has been working on interval arithmetic, important details of potential specifications appear to have changed.
On the second point, various ways of incorporating interval arithmetic into Fortran have been considered by J3; for example: as a new intrinsic data type, as an encapsulated derived type, and along the lines indicated in WG5-N1303. Significant deficiencies in the base language currently prevent quality implementations using any of these approaches; examples include:
(a) greater need for control of "interline assignment optimization"
(as touched upon by papers 97-158, 97-198, and 97-199)
(b) more control of rounding modes in both operations and I/O
(c) deficiencies in the derived type abstraction mechanisms
For these reasons J3 requests permission from WG5 to make the recommended change in the nature of this requirement, focusing for Fortran 2000 upon repairing the deficiencies in the Fortran base language in order to facilitate accommodating interval arithmetic in a future version of the standard.