J3/99-109 Date: February 15, 1999 To: J3 From: Wolfgang V. Walter Subject: DIN comments on derived-type I/O Ref: J3/98-134r2 ---------------------------------------------- The DIN Fortran working group discussed the current draft for derived-type I/O at its last meeting and would like to offer the following comments: 1. Requirements for derived-type I/O --------------------------------- The requirements which were found by DIN match the ones stated in J3/97-217r1 fairly closely, but stress a few aspects differently. a) Support for hierarchical derived type definitions and data abstraction: It should be possible to define modules which fully encapsulate all operations for a derived type, including its I/O. If an encapsulated derived type is used as component type of another derived type, the I/O handler for this derived type may know, but should not be forced to know any details of the I/O of the embedded derived type. In particular, it should be able to simply call the I/O handling routines of its component types. It should also be possible to prescribe the desired formatting for a higher-level derived type to any desired level of detail and accuracy. This could involve the specification of lower-level formatting for component types, and it requires some sort of nesting within the DT edit descriptor. In other words, the hierarchical/nested structure of derived types should be mimicked by an edit descriptor syntax that allows an analogous hierarchical/nested structure. b) Syntax for derived types: The syntax for derived-type edit descriptors should - be close to the standard Fortran syntax and use existing syntax where appropriate, e.g. when certain components are of intrinsic type and need explicit formatting, - allow the specification of fairly complicated edit specifications, i.e. a priori limits on the number of "parameters" (e.g. field widths, repeat factors, etc.) should not be imposed, and - allow nesting of DT edit descriptors for nested derived types. c) Support for standard Fortran formatting within I/O handlers: If a derived type I/O handler wants to implement standard Fortran editing for some derived type components, it should not have to implement the whole Fortran format editing completely by itself. Rather, there should be language features (e.g. runtime routines) which help the I/O handler to parse standard format syntax or handle standard edit descriptors. d) Support for OOP: Derived-type I/O should also support the object-oriented features envisaged for Fortran 2000, as e.g. polymorphic types. It is not clear yet if this requirement will affect the draft, but there should be another check as soon as the OOP concepts are finished. 2. Suggestions regarding the current draft for derived-type I/O ------------------------------------------------------------ a.) Syntax for derived-type edit descriptors: The current syntax does not support requirements a)+b) above, especially since it does not adequately allow the nesting of module-encapsulated derived types. Suggestion: The syntax of a DT edit descriptor might be defined as: DT() Example: DT(2I5,A10,A,2F10.5,DT(ROUND_TO_LOW,'abcde',I5),2A6) This syntax would allow nesting DT edit descriptors, and the I/O handler does not necessarily need to know the syntax for embedded derived types. For simple cases, a simpler form without enclosing parentheses (as the current syntax suggests) could be maintained. b.) Support of standard edit descriptors: To support requirement c) above, there should be some intrinsic subroutines which allow the parsing of a standard format string in I/O handlers which allow standard edit descriptors as part of their derived type editing syntax. The standard subroutine could e.g. parse the next element (until the next comma or end-of-string) of some format string and deliver as result the repeat factor, the format type (A, I, F, E, DT, literal string...), the length paramter(s), the full edit string without repeat factor (ready for use in child I/O statements) and the literal value in case of literal or DT edit descriptors. c.) Support of I/O within I/O handlers: We do not understand the restriction that a DT-I/O handler must not do any I/O on other units. (The restriction is necessary for the current unit, but why the restriction for *other* units?) We thought of many cases (e.g. an I/O handler opens, reads, and closes a parameter file at its first invocation) where I/O on other units is desirable or necessary. d.) INQUIRE for IOLENGTH: Is there any support for INQUIRE by IOLENGTH? (We could not find any.) Assumption: the unformatted WRITE subroutines are also called in case of INQUIRE, but any output produced is ignored. In any case some more wording will be needed. e) UNIT parameters: In case of UNIT=* or internal I/O, a negative unit value is passed to the I/O handler. What is the handler supposed to do with it? We assume it may use this negative unit value in READ/WRITE statements to address the "current" unit number, and that negative unit values are accepted in this case, but we could not find corresponding wording. ======================================================================= Prof. Dr. Wolfgang V. Walter Dresden University of Technology Institute of Scientific Computing Department of Mathematics D - 01062 Dresden Germany Tel: +49 - 351 / 463-3996 or -4266 (secr.) FAX: +49 - 351 / 463-7096 e-mail: wwalter@math.tu-dresden.de