Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!uwm.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!uqv-mts!Al_Dunbar From: userAKDU@ualtamts.BITNET (Al Dunbar) Newsgroups: comp.lang.fortran Subject: Re: Was: Re: length of a character string Message-ID: <2494@ualtamts.BITNET> Date: 27 Sep 89 20:16:34 GMT References: <2490@ualtamts.BITNET> <125348@sun.Eng.Sun.COM> Organization: University of Alberta (MTS) Lines: 84 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 stringsdelimited 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" -------------------+-------------------------------------------