Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!chiba!khb From: khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) Newsgroups: comp.lang.fortran Subject: Re: Was: Re: length of a character string Message-ID: <125348@sun.Eng.Sun.COM> Date: 27 Sep 89 06:07:08 GMT References: <2490@ualtamts.BITNET> Sender: news@sun.Eng.Sun.COM Reply-To: khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) Organization: Sun Microsystems, Mountain View Lines: 128 In article <2490@ualtamts.BITNET> userAKDU@ualtamts.BITNET (Al Dunbar) writes: > >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 >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 And cryptic it is. The thing being varied isn't a collection of characters, but the _size_ and _encoding_ of characters. For full Kanji support, for example, it is necessary to have some stuff be regular "ascii" (aka romanji) and some stringsdelimited in the various formats popular in nihon. >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. At the Long Island meeting this spring (the last one I attended; Gary Campbell represented us in the European venue) there were two newcomers ... one from the Ada community ... who was very impressed at how much detail goes into f8x debate ... he indicated that the Ada 9x committee seldom had folks understand the issues enough to have proper debate ... not a problem in an X3J3 gathering. It is unfortunate that Metcalf and Reid's revised text is not yet shipping (I haven't received my copy yet, so I _assume_ others haven't either :>), the offical text itself must (alas) lack everyone's reasoning ... and it is hard enough to agree on the text much less a commentary. It is my understanding that some of the European groups are much cleverer about distribution than americans (I don't know the status of the Canadian groups ... I don't recall meeting a rep from there). BSI (the brits) tend to publish BSI offical summaries, commentaries, etc. .... >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 As an employee of a company doing work in that area, I am begining to appreciate the mistakes of ANSI C. There is the notion that, for example, that ANSI C "fixes" the math library problems ... now there are several different (mutually exclusive) compliance tests, SVID, POSIX, and ANSI ... all are different and all are quite wrong if what you want is correctness and speed. There is a numerical C group (originally called into being by Cray, I think) which is attempting to bring some order to the chaos. It is too early for me (especially as I am not generally a C language lawyer) to really be sure, but I suspect that the asynch IO ANSI defn will break codes nominally portable across certain unix boxes ... > >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_ Actually under SunOS 4.0+ and ATT V.4 and a little clever C code (can be done in f77v1.3 but is tricky), mmap can be employed to take the whole file and associate it with a variable ... then all IO is just assignments to the variable. Clearly this is not the sort of behavior that one should try to code into a OS indpendent definition! >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. I have forgotten details of the debate; but PROMPT= was considered at length and rejected. I think that part of the unease was that PROMPT= installed yet another semantic ... that of tying the output to some (undefined) input unit. In unix, for example, the "native" association (*typically*) is stdin=unit 5, stdout=unit6 and stderr=unit 0. Now should PROMPT= be referring to units 6 and 5 or 6 and 0 ? What if some other unit is the output file (say 60 ?). NOS sets up (it has been a long while, so this could be flakey) the associate with TAPE= statements ... there is no real apriori association ... etc. Remember that this is merely one of dozens of points considered. Different proposals were crafted by authors who spent months cooking them up. Subcommittee made fixes/recommendations/etc and full committee detbated at length. I think (since I am too lazy to dig up the attendence sheets) that there were on the near order of 50 people involved in the debate (not all were voting members) and some fraction of them were _very_ well informed on all the details.... and the proposal which carried the day had on the order of 34 votes in its favor ... this does not ensure correctness ... but having the necessary functionality was considered quite important. You are most certainly invited to attend any of the committee meetings, there are several folks well seeped in the 10+ years of delibrations who would be happy to explain the issues over a beer (not all of the members have ready net access, or inclination to be active in this forum). I/O is not a subcommittee whose work I have followed too closely ... so I am by no means the best authority to assert what was considered and why ... cheers Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"