Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!uqv-mts!Al_Dunbar From: userAKDU@ualtamts.BITNET (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Was: Re: length of a character string Message-ID: <2490@ualtamts.BITNET> Date: 26 Sep 89 14:06:14 GMT Organization: University of Alberta (MTS) Lines: 82 Summary: Rationale for "Non-advancing I/O" Thanks to Keith H. Bierman for setting me straight on a number of points regarding the proposed Fortran 8X standard as it relates to varying length strings and non-advancing I/O. (I would have posted a followup, but by the time I was ready, his article was no longer unavailable). I can easily live without varying length character variables, as the standard provides other facilities that may be used in their place, namely pointers and modules. Mr. Bierman wrote: >Mr. Dunbar writes: >>Rather than putting it directly into the standard at this late >>date, however, a compromise was reached. The concept of non- >>advancing I/O was ... >Has nothing to do with varying length string proposals. If this is indeed the situation, how do you explain the following paragraph, extracted from ISO/IEC JTC1/SC22/WG5 document N395, entitled "Summary of Changes to Fortran Draft", in the section entitled "Rationale for Major Changes to Draft Fortran Standard": > INPUT/OUTPUT > > 1. Partial Record I/O added > > The international community provided most of the public comment on > character processing, such as described above for Kanji support. Another > request from this community was for varying character capability. It was > finally agreed that the best way to provide this was as a varying > character module, but that some sort of stream I/O (e.g. > GETCHAR/PUTCHAR) was needed to do that. As a stream I/O facility would > have much wider use than just this application, it was decided to add a > stream I/O capability to Fortran 8X. Initially considered were GETCHAR > and PUTCHAR intrinsic functions. However, the final decision was to add > versions of the READ and WRITE statements that work on only part of the > current I/O record -- hence, the term partial record I/O. I apologize if I have misunderstood, but the above text is the _ONLY_ explanation I have as yet seen for the appearance of Non-advancing I/O that has _ANY_ official stamp on it. This and the comments of fellow members of CSA/CPL/FWG who have represented Canada at various WG5 meetings. It is indeed unfortunate that it is not easier to determine the actual reasoning that goes into the various decisions made by X3J3, and further, that this lack of information occasionally suggests (incorrectly, in most cases I hope) a lack of rigorousness in the proceedings. Mr. Bierman further writes: >Asynchronous I/O is very hard to specify in a completely OS independent >fashion. The current proposal should cover character at a time (though >one expects there to be efficiencies for grabbing more per transaction) >and asynch extensions are probably planned by most of the vendors whose >operating systems support such things. True to the first sentence. This may, however, be more a case of asynchronous I/O just being new to Fortran, as the X3J11 committee is having no problems with this issue in the C standard. Consider how the Fortran standard allows for the use of cataloging (i.e. "filenames") while stating that this capability is not a requirement of the processor. Granted, many vendors will supply Asynchronous I/O features; unfortunately, some via ADVANCE=NO, and some via GETCHAR/PUTCHAR, as the standard basically says NOTHING about how it could or should be done. For example, if ADVANCE=NO is used for terminal input, how could the echo be suppressed? As proposed, Non-advancing I/O (NAI/O) allows for (at least) two new capabilities which I applaud: the reading of *LARGE* records without the need for a large buffer internal to the program, and the determination of actual record length. However, the first _can_ be done with a varying execution time format and a BACKSPACE statement, while the second _could_ be done by allowing the IOLENGTH= keyword to be applied to READ statements as well as INQUIRE's. NAI/O does NOT seem to make up for the loss of the PROMPT= keyword, as I can find no indication that partial output records will ever be emitted until the end of record is specified. I find PROMPT= to be much simpler approach to this, as the program would not have to determine which unit should be used to issue the prompt or when prompts should be suppressed because input was coming from a file rather than a terminal. -------------------+------------------------------------------- Alastair Dunbar | Edmonton: a great place, but... Edmonton, Alberta | before Gretzky trade: "City of Champions" CANADA | after Gretzky trade: "City of Champignons" -------------------+-------------------------------------------