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 strings  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"
-------------------+-------------------------------------------