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