userAKDU@ualtamts.BITNET (Al Dunbar) (09/26/89)
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" -------------------+-------------------------------------------
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (09/27/89)
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 strings <esc> delimited 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"
userAKDU@ualtamts.BITNET (Al Dunbar) (09/28/89)
In article <125348@sun.Eng.Sun.COM>, khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) writes: >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 > >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 strings <esc> delimited in the >various formats popular in nihon. > I appreciate the "crypticness" of N395, as well as _some_ of the issues of inter/national character set support (which I had _thought_ were satisfied by multibyte characters, whether via NCHARACTER or CHARACTER(KIND=2)). Whatever "varying character" may mean, however, the document still suggests that the addition of NAI/O was in some way driven by a need for some sort of module required to implement "varying character", and that consideration of a new form of I/O for its own sake seemed somewhat secondary. >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. I am glad to hear such comments. It is regretable that X3J3 has been unable to generate better PR. I appreciate some of the problems inherent in the process, but that appreciation has come mostly through my membership in CSA/CPL/FWG (and now your comments). > 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. Not to offend Global Engineering, but, if we ask all those expressing an interest in 8X to get their "official copy", they will not have time to formulate a reasoned comment. We freely circulate (internally, anyway) copies of our (CSA/CPL/FWG) copy. Ignoring or rejecting public comments from individuals WHO DID NOT PURCHASE THEIR OWN OFFICIALLY SANCTIONED COPIES (as has been suggested might be the case) would be a travesty. It would be better to reject those comments that are based on an obviously incorrect copy. >> 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. The answer is, that the PROMPT= keyword puts the ball in the o/s's court, which has a much better chance to make the appropriate determination than a Fortran program, regardless of whether the appropriate device is connected to a Fortran I/O unit. What if one can't, you might ask -- well, what does the standard say about how systems not using filenames are to treat FILE= and NAME= keywords? Having made all these comments, I will close with the standard clause we put on most of our submissions to X3J3 and/or WG5: "We would like to see this feature added/deleted/modified, but NOT at the expense of preventing a timely release of a long overdue Fortran Standard". -------------------+------------------------------------------- Alastair Dunbar | Edmonton: a great place, but... Edmonton, Alberta | before Gretzky trade: "City of Champions" CANADA | after Gretzky trade: "City of Champignons" -------------------+-------------------------------------------
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (09/28/89)
In article <2494@ualtamts.BITNET> userAKDU@ualtamts.BITNET (Al Dunbar) writes: > >I am glad to hear such comments. It is regretable that X3J3 has been >unable to generate better PR. I appreciate some of the problems inherent >in the process, but that appreciation has come mostly through my >membership in CSA/CPL/FWG (and now your comments). One does what one can ... if ANSI were a profit making organization, perhaps a PR firm could be retained ... :> >Not to offend Global Engineering, but, if we ask all those >expressing an Many members of X3J3 were extremely displeased that X3 (the parent committee) refused permission to have the standard widely distributed. It appears that Fortran documents are such popular documents that they are treated as a fund raising event ... as Walt posted a couple of weeks back, Tom Lahey's company is distributing copies (clean readable ones) for cost. >from individuals WHO DID NOT PURCHASE THEIR OWN OFFICIALLY SANCTIONED >COPIES (as has been suggested might be the case) would be a travesty. It >would be better to reject those comments that are based on an obviously >incorrect copy. Presley Smith was offering his own "legalistic" opinon. Presley is a very smart guy, and is probably legally correct (so if you plan to sue ANSI retain him :>) but I seriously doubt that X3J3 will reject opinons based on where you got your copy. >The answer is, that the PROMPT= keyword puts the ball in the o/s's court, >which has a much better chance to make the appropriate determination than >a Fortran program, regardless of whether the appropriate >device is I beg to differ ... putting behavior directly into the programmers hands seems to moi as more likely to produce repeatable results on different platforms. >Having made all these comments, I will close with the standard clause we >put on most of our submissions to X3J3 and/or WG5: "We would like to see >this feature added/deleted/modified, but NOT at the expense of preventing >a timely release of a long overdue Fortran Standard". amen. 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"
psmith@mozart.uucp (Presley Smith) (09/28/89)
In article <125409@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) writes: -- Text Deleted -- > >Many members of X3J3 were extremely displeased that X3 (the parent >committee) refused permission to have the standard widely distributed. >It appears that Fortran documents are such popular documents that they >are treated as a fund raising event ... as Walt posted a couple of >weeks back, Tom Lahey's company is distributing copies (clean readable >ones) for cost. Presley is as just as displeased at the lack of permission to widely distribute the document as the other members of X3J3 are. > >>from individuals WHO DID NOT PURCHASE THEIR OWN OFFICIALLY SANCTIONED >>COPIES (as has been suggested might be the case) would be a travesty. It >>would be better to reject those comments that are based on an obviously >>incorrect copy. > >Presley Smith was offering his own "legalistic" opinon. Presley is a >very smart guy, and is probably legally correct (so if you plan to >sue ANSI retain him :>) but I seriously doubt that X3J3 will reject >opinons based on where you got your copy. Once again... 1. You do NOT have to purchase a copy of the document to comment on Fortran 8x. It would help if you are informed about Fortran 8x prior to commenting. You should get information on both the positive and negative aspects of the proposed standard and make an informed decision on what you feel about the document. There's a lot of emotion on this issue. There's a lot of selling going on both on the positive and the negative side. IF YOU SEE A PRESENTATION ON FORTRAN 8X THAT IS EITHER ALL POSITIVE, THE WORLD IS GREAT, OR ALL NEGATIVE, THE SKY IS FALLING, YOU SHOULD BEWARE. It's NOT all positive and it's NOT all negative. You should require a balanced view from information that you receive. 2. Tom Lahey has every right to distribute the document. But Tom is not the official distribution channel. From the ANSI point of view, it's possible that an update to the document might be made during the public review period. If this was the case, then the official distribution channel would inform you of such an update and you could obtain it. ANSI is not required to work with Tom to be sure you get the same information. If something is wrong with the document that Tom is distributing, (I don't believe there is...but IF...) and you comment on the thing that is wrong and the document from the official sanctioned place is right... then if you make an appeal to ANSI based on information that is wrong from a non-sanctioned document, ANSI does not have to listen to that appeal... you based your appeal on information that was in a document that was NOT sanctioned. Complicated enough? To my knowledge, Tom`s distribution is exactly the same document that Global is distributing. It is certainly Tom's intention to make it such. The ANSWER IS... GET A COPY OF THE DOCUMENT and/or GET A BALANCED PRESENTATION ON THE POSITIVE AND NEGATIVE ASPECTS OF THE DOCUMENT and WRITE. DON`T WORRY about the possible legalise of the scanctioned or non-sanctioned documents...
bill@ssd.harris.com (Bill Leonard) (10/04/89)
> The answer is, that the PROMPT= keyword puts the ball in the o/s's court, > which has a much better chance to make the appropriate determination than > a Fortran program, regardless of whether the appropriate device is > connected to a Fortran I/O unit. What if one can't, you might ask -- well, > what does the standard say about how systems not using filenames are to > treat FILE= and NAME= keywords? One thing that seems to get missed in this (and other) debates is what is POSSIBLE in a standard. For instance, a previous article complained that non-advancing output didn't force the output to appear until end-of-record was written. Quite true, but then NEITHER DID PROMPT=!!!! The standard doesn't even have a way of talking about what it means for output to "appear". The real answer to all this is, "it is a quality of implementation issue". If your vendor implements non-advancing I/O in a stupid and useless way, then find another vendor. I'm sure there will be plenty who will do it the way all of us intend it to be, and in a way that works to the user's advantage. There are just some things you cannot say in a standard. Section Notes sometimes are used to tell implementors and users what was intended, but they aren't binding on anyone. Such is life... -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or hcx1!bill@uunet.uu.net