ISO/IEC JTC1/SC22/WG5 N1895 Result of WG5 letter ballot on N1885 and N1886 John Reid N1890 asked this question Please answer the following question "Are N1885 and N1886 ready for forwarding to SC22 as the DTS and the response to the PDTS ballot?" in one of these ways. 1) Yes. 2) Yes, but I recommend the following changes. 3) No, for the following reasons. 4) Abstain. The numbers of answers in each category were: 3 for 1) Yes. (Chen, Moene, Whitlock) 3 for 2) Yes, but I recommend the following changes (Bader, Long, Snyder) 2 for 3) No, for the following reasons. (Corbett, Reid) 1 for 4) Abstain. (Muxworthy) Here are the responses in detail _______________________________________________________________________ Reinhold Bader 2) Yes, but I recommend the following changes. (Change 1) Appendix A.2.6, para 1: replace "has several functions" by "includes procedures" Reason: The Fortran interface uses subroutines, not functions. (Change 2) Appendix A.2.6, para 1: after "is similar to the", insert "second variant of" delete "; however it uses assumed rank ... than assumed size" Reason: As is, the reference to A.1.2 appears confusing since two methods are described there. (Change 3) Appendix A.2.6, para 2 (after the C prototype for MPI_send_f): replace "there is a conversion between" by "there exists a conversion facility between" delete "be" in "is also be done" Reason: Wording improvement/correction (Change 4) Appendix A.2.6, para 4 (after the C prototype for MPI_Comm_set_name_f): replace "can be defined in the module," by "are assumed to be defined in a module" Reason: Wording improvement (Change 5) Global edit Three quoting methods are used in N1885 for the binding labels in BIND(C, name=...) statements. It is suggested to use the double quote (") everywhere (although admittedly the standard itself is not entirely consistent here). (Change 6) 8.3.5.5 CFI_establish, para following the argument descriptions italicize "attribute" in "; if the attribute argument ..." Reason: typographical convention _______________________________________________________________________ Daniel Chen: 1) Yes. _______________________________________________________________________ Robert Corbett 3) No, for the following reasons. 5.4 ASYNCHRONOUS attribute My greatest concern is still Clause 5.4. A small point first. Clause 5.4.1 states that asynchronous communication is initiated and completed by procedures written in C. Clause 5.4.2 states that asynchronous communications occurs through the action of procedures "defined by means other than Fortran." Those statements are not equivalent. Furthermore, both statements exclude an important possibility, namely that a Fortran processor might provide nonstandard intrinsic procedures that perform asynchronous communications. The statement in paragraph one of Clause 5.4.2 that whether a procedure is an asynchronous communication initiation or completion procedure is "processor dependent" might be misleading. Malcolm asserted that a procedure either is or is not an asynchronous communication procedure is determined by the procedure. Until I saw Malcolm's e-mail, I thought the draft TS meant that the processor would recognize a set of routines as asynchronous communication procedures. Malcolm's interpretation makes more sense, but the current text seems ambiguous. I would like the "processor dependent" statement to be replaced by language that says that an asynchronous communication procedure is one that initiates and/or completes asynchronous communication. My last concern is that the text in the draft TS does not address the impact of Clause 5.4 on processors. Bill said that the Fortran 2008 standard does not address the impact of asynchronous I/O on processors. I concede that the normative text of the standard does not (and I consider that a defect), but Clause C.6.6 does describe the intended effect. If the normative text of the TS does not address the intended impact of asynchronous communications procedures, a note similar to C.6.6 should be provided for asynchronous communications procedures. I would like definitions of asynchronous initiation procedures and asynchronous completion procedures to be added to Clause 3 "Terms and definitions." ------------------------------ 8.3.2 CFI_dim_t I still think the extent field should be an unsigned type, not a signed type. I do not think the definition of CFI_index_t is adequate. I would be satisfied by a note added to the TS explaining that range of values of a CFI_index_t might not include all values of bounds and extents used by a Fortran program. ------------------------------ 8.3.4 Macros I agree with Van that a macro for an attribute code for scalars should be included in Table 8.1. If no such macro is provided, then the TS should state how scalars are to be handled. Bill said that a scalar should be given the attribute code CFI_attribute_unknown_size. The only way I see to derive that information from the existing text is by elimination. _______________________________________________________________________ Bill Long: 2) Yes, but I recommend the following changes. Apart from the changes in the boiler plate requested by the ISO editor (and already entered into the LaTeX sources), the comments I had seem to be covered by other ballots. _______________________________________________________________________ Toon Moene: 1) Yes. _______________________________________________________________________ David Muxworthy: 4) Abstain _______________________________________________________________________ John Reid: 3) No, for the following reasons. I would like the following changes to be made to N1885. 6.3. Change the last two sentences of para 1 to "If the actual argument is an array, the rank of the dummy argument is assumed from the actual argument. If the dummy argument is neither a pointer nor allocatable, its shape is assumed from the actual argument." Reason: It is not intended that both bounds be assumed from the actual argument. However, it is intended to allow an assumed-rank object that is neither a pointer nor allocatable to be an actual argument corresponding to an assumed-shape array. In this case, the shape must be available. 8.2. In line 2, change "assumed character length, assumed rank" to "assumed size". Reason: See the list of possible attributes in Table 8.1. 8.3.5.7. Replace the two paras before the Result Value para by "On successful execution of CFI_section, the \cf{base_addr} and \cf{dim} members of the C descriptor with the address \cf{result} describe a section of the array described by the C descriptor with the address \cf{source}. If an error is detected, that C descriptor is not modified." Reason: Make it clear that the change happens only if the call is successful and say which members are changed. 8.3.5.8. Replace the first sentence of the para before the Result Value para by "On successful execution of CFI_select_part, the \cf{base_addr}, \cf{dim}, and \cf{elem_len} members of the C descriptor with the address \cf{result} are updated." Reason: Say which members are changed. 8.3.5.9. Replace the first sentence of the para before the Result Value para by "On successful execution of CFI_setpointer, the \cf{base_addr} and \cf{dim} members of the C descriptor with the address \cf{result} are updated." Reason: Say which members are changed. 8.3.9, para 5. Change "If a dummy ... actual argument; the" to "In a reference to the C procedure from Fortran, if a formal parameter of the prototype is a pointer to CFI_cdesc_t, the corresponding formal parameter of the reference is interpreted as the address of a C descriptor with the following properties (1) if the dummy argument is allocatable or a pointer, the C descriptor shall describe the actual argument; (2) otherwise, if the dummy argument is assumed rank, the C descriptor shall describe the actual argument as an assumed-shape object; (3) otherwise, if the actual argument is assumed size, the C descriptor shall describe the actual argument; (4) otherwise, if the actual argument is a pointer, the C descriptor shall describe the target of the actual argument as an assumed-shape object; (5) otherwise, the C descriptor shall describe the actual argument as an assumed-shape object. In a reference to the Fortran procedure from C, if a formal parameter of the prototype is a pointer to CFI_cdesc_t, the corresponding argument shall be the address of a C descriptor with the following properties (1) if the dummy argument is of assumed rank or is a nonallocatable, nonpointer variable of type CHARACTER with assumed length, the C descriptor shall describe an assumed-shape object; (2) otherwise, the C descriptor shall describe an object with the properties declared in the Fortran interface for the dummy argument. The" Reason: The present wording is insufficiently precise about which value should be given to the attribute member in the C descriptor. _______________________________________________________________________ Van Snyder: 2) Yes, but I recommend the following changes. 5.1p3 Note 5.2: Replace "within Fortran code" by "for a Fortran procedure" 5.4.2p1: It seems to be OK for a processor to decide that pure real function xyz ( x ) integer, intent(in) :: x xyz = x + 1.0 end function xyz is an asynchronous communication initiation or completion procedure. 6.3p1: With the being there's no place to write explicit lower bounds. Therefore, all elements of the LBOUND result would be 1. The last sentence ought to be something like "The value of the lower bound of each dimension of the dummy argument is 1, and the value of the upper bound of dimension N of the dummy argument is equal to the result of applying the SIZE intrinsic inquiry function to the actual argument with DIM=N specified." 6.4.1p1: I don't understand how the expression can work. 6.4.3p1: After "result" insert "of UBOUND(ARRAY,RANK(ARRAY),[KIND])". 8.3.4p6: It's not obvious what attribute code ought to be used for an assumed-length character scalar. CFI_attribute_assumed is probably the correct one, but (if so) the description ought to say so. 8.3.5.2p3: The symbol $r$ appears without explanation. After "array" insert "of rank $r$". 8.3.5.2p2, description of "subscripts": Is the order of subscripts the Fortran order or the C order? 8.3.5.2p5: The example would be more informative if the subscripts were different. Inquiring minds might realize that Fortran and C subscripts have opposite ordering, and wonder which order they ought to appear in the subscripts array. 8.3.5.3p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Allocates" with "Allocate". 8.3.5.3p2, descriptions of "lower_bounds" and "upper_bounds": Is the order of elements in the arrays the order of C array bounds or Fortran array bounds? 8.3.5.3p4: Is dv->elem_len updated if no error is detected? 8.3.5.3p7: The example would be more informative if the bounds were different. Inquiring minds might realize that Fortran and C bounds have opposite ordering, and wonder which order they ought to appear in the lower and upper arrays. 8.3.5.4p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Deallocates" with "Deallocate". 8.3.5.5p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Establishes" with "Establish". 8.3.5.5 generally: It's not obvious how to establish an assumed-length character scalar. 8.3.5.5p2, description of "extents": Is the order of extents the Fortran order or the C order? 8.3.5.7p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "Updates" with "Update". 8.3.5.7p2, description of "lower_bounds" and "upper_bounds": Is the order of elements in the arrays the order of C array bounds or Fortran array bounds? What is "the given array?" Should this be "the array described by the descriptor dv?" Is it OK for the number of elements to be > source->rank? 8.3.5.7p2, description of "strides": Is the order of elements in the array the order of C array bounds or Fortran array bounds? Is it OK for the number of elements to be > source->rank? 8.3.5.8p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "CFI_select part updates" with "Update". 8.3.5.8p2: It's not obvious how (or even if it's possible) to select a substring of a character array. 8.3.5.9p1: The style for descriptions in 1539-1 is telegraphic, and in active rather than passive voice. Replace "CFI_setpointer part updates" with "Update". 8.3.8p5 Note 8.12: "bind(c)" should be "bind(c,name='Cfun')", or "Cfun" in the narrative should be "cfun". 8.3.9p2,p3(1): "BIND" should be "BIND(C)" 9.11p1: Values specified by attribute macros should be in the list. _______________________________________________________________________ Stan Whitlock: 1) Yes.