To: DIN J3/99-111 From: J3 page 1 of 2 Subject: Response to DIN DT I/O comments Date: March 2, 1999 Ref: J3/99-109, N1322 The JOR subgroup has reviewed your comments on derived type I/O (J3/99-109), and has responded to the various points therein below. Summary (detailed comments below) We note that WG5 has previously provided requirements for the development of this facility, and in paper N1322, provided what we believed to be the final requirements, and a plea for interested parties to participate in finishing up the work on this requirement. Some of the suggested requirements in 99-109 are already supported by the current proposal. Other requirements involve new functionality. We believe it is too late in the F2000 process to make major changes in the requirements, and some of the functionality requested in 99-109 is both brand new, and a significant effort (in terms of developing the edits to the draft standard). One requested feature (reentrant I/O) is not properly part of derived type I/O, but is a more general I/O feature. Other points from 99-109 have or will be addressed as indicated below. Point by Point Responses (1a) Support for hierarchial derived type definitions and data abstraction Response: this has always been a key design goal, and we believe the current edits in the standard provide this capability in an acceptable manner. The first paragraph in 1a) states "In particular, it should be able to simply call the I/O handling routines of its component types." The restriction against directly calling these routines was removed at J3 meeting 147, and the edits made in 99-007 reflect this. The 2nd paragraph requests an edit descriptor syntax that supports/mimics the hierarchial structure of nested derived types. The current proposal does not prevent such syntax from being used. The suggested changes in syntax from 2a), would be legal under the current proposal with minor changes: DT(2I5,A10,A,2F10.5,DT(ROUND_TO_LOW,'abcde',I5),2A6) DT"(2I5,A10,A,2F10.5,DT(ROUND_TO_LOW,'abcde',I5),2A6)" (1b) states some syntax goals for DT I/O. Response: ALL of the suggested capabilities are allowed under the current proposal, but there is no "enforcement" of a nested structure, nor any explicit help for parsing such a format string. Trying to enforce such a nesting structure directly violates earlier WG5 requirements for derived type I/O. (1c) Providing some intrinsic or other routines, to aid parsing of "standard" edit descriptor strings. Response: This is a new suggestion, and J3 believes that trying to add this new functionality at this late date would delay the completion of the draft standard, and is not appropriate. J3/99-111 page 2 of 2 (1d) OOP support Response : J3 (the JOR subgroup) will investigate this issue and suggest appropriate changes, if any, sometime in 1999. Please send any suggestions to the J3 mailing list. (2a) suggests that derived type I/O support for nested derived types is insufficient, and suggests some syntax changes. Response: J3 notes that by adding 2 quotes, the syntax described is allowed. J3 also notes that enforcing such syntax violates earlier WG5 direction in this area. (2b) asks for new routines to aid in parsing standard edit descriptors. Response: As noted above, J3 feels this would delay completion of the draft standard, and is not an appropriate change in specifications at this time. (2c) asks for a new I/O capability, "reentrant" I/O, where concurrent I/O to different units would be permitted. Response: This functionality is not related to derived type I/O, and J3 feels this must be pursued as a separate work item, and not hidden in derived type I/O. Also, J3 notes that some vendors supporting parallel processing have provided this capability, and although conceptually simple, is likely to take considerable effort to integrate this capability into the standard. (2d) asks about INQUIRE by IOLENGTH. Response: Unlike traditional I/O formatting, there is no correlation between the "buffer size" needed by derived type I/O for a particular I/O list item and any other I/O list item of the same type. Indeed, a derived type I/O routine is not required to produce the same output on two successive calls, even with the same "value". It is expected that derived type I/O routines will produce/consume different amounts of data based on the values of components, allocation status of components, length of linked lists, etc.. Because the length returned by an INQUIRE for a user defined derived type I/O routine is often not useful, and in particular, not necessarily suitable for use as a RECL= value as required by section 9.8.3, J3 intentionally decided to NOT provide INQUIRE by IOLENGTH for user defined derived type I/O routines. We also note that the new STREAM I/O capability will reduce the need for INQUIRE by IOLENGTH. (2e) asks what the negative unit number for UNIT=* or an internal unit is to be used for. Response: The unit number should be used as the UNIT= value for all I/O statements intended to affect the original unit specified by the user in the parent I/O statement. This unit value was specified to be negative to provide a simple way for the user to avoid calls to INQUIRE for these particular cases, since INQUIRE on the "*" unit (and internal units) is currently prohibited. J3 notes that a pending proposal for accessing the unit numbers for the two different "*" units may affect this, and we will modify the derived type I/O proposal appropriately. J3 will also scan the standard to ensure that using the "negative" unit numbers in child I/O statements is not prohibited by any existing text.