Clive Page said:
> On Fri, 20 Nov 1998, Malcolm Cohen wrote:
> 
> > A strange idea, since it does ***not*** end the (Fortran) record.
> 
> I think we differ in what the term "record" means.  Yours is a rather 
> Unix-centric definition, in which a record is identical to a line
> of text, and on a Unix system this always has to be terminated by a
> line-feed (other systems have their own conventions, unfortunately).
>
> I was using the term "record" in its Fortran sense: a sequence of

So was I; I was not using it in a Unix sense, since Unix does not have
proper "records" as such.

It is easy to count the Fortran records in a Fortran file with a
Fortran program; that is the definition I was using.  But see below.

> characters output by a WRITE statement; I think that I am correct in
> asserting that a formatted non-advancing WRITE always outputs at least one
                            ^^^^^
I think you just mean "advancing", here.

> record (>1 in some circumstances e.g. if the format includes a slash
> descriptor).

For standard-conforming programs you are correct.  However, "$" makes
the program non-conforming, so all bets are off.  (And the results
differ on different systems, as described below).

> On other operating systems, such as VMS, the processing of
> records is quite separate from the issue of what line terminator or
> separator is attached to it.

The actual situation is a little more complicated than that.

There is no "line terminator" attached to a Fortran text file in VMS
at all other than the end-of-record information (which for a disc file
is a byte count preceding the actual record value).

The effect of "$" on VMS is different for terminals and disc files.

For terminals, "$" suppresses the CR; but only if the next i/o to the
terminal is a READ.  If the next i/o is a WRITE the CR is inserted.

For disc files, "$" puts a "$" into the carriage-control position of
the record (at least if you have a blank there).  This seems to be
treated just the same as a blank by "TYPE".  This "$" is available to
read as data by a Fortran program though, it does not read as a blank.
[I think this gives a clue as to how "$" is implemented ... i.e. it is
an extra carriage-control character that overrides the supplied
carriage control character].

The effect of "$" on Unix is the same for terminals and disc files.
It always suppresses the CR(LF); i.e. it writes partial records (if
you read them back in with a Fortran program they are joined to the
following record).

> standard, but DEC Fortran 90 supports this extension, and their Language
> Reference Manual says "the dollar sign descriptor suppresses carriage
> return (after printing the record)".  I suspect this is a typical
> definitialn.

Typical on VMS, not on Unix.  As described above, the data written
using "$" is rather non-portable.

> This suggests to me that the $ descriptor transfers a
> complete record to be output (complete except for the line-terminator
> characters, whatever they are),

True for VMS only, untrue for Unix.

> whereas advance="no"  only produces a partial record.

Yes, and on Unix this is the same as "$".

>  Most systems seem to use the Posix flush rules, which
> means they flush after a record even if produced with a $ descriptor, but
> not after a partial record from advance="no".

Most don't flush after advance='no'?  This is somewhat arguable.

I just tried it with:
  SUN, IBM, SGI, DEC, EPC and Fujitsu; and Fujitsu was the only one
  that did not flush after advance='no' (and it was an old copy anyway).

So in my experience, almost everyone gets this right.

> So this takes me back to my original point.  When the draft for F8X was
> open for public comment I thought that the non-advancing output proposal
> was a bit over the top, but that it would be an adequate replacement for
> the $ format descriptor.

Well it was meant to do more than "$", that is why it does do more.

>  Maybe others thought the same, because as
> far as I am aware, there were no proposals to introduce the $ format
> descriptor.  I now realise that I was wrong, which means that systems
> which support the $ descriptor provide functionality which some programs
> need, and which cannot be obtained merely with advance="no". 

IMO (and the O of Many): They have poor quality non-advancing i/o.
Simple explanation: the vendor did not think of it at the time (an
easy mistake since the standard writers "forgot" to put in any
explanation that this should be usable for prompts ... probably
because the people who wanted it to do this thought it was obvious).

But whichever had been done, it would still have boiled down to QOI,
like the standard does not define 2+2=4 etc.  The mistake that does
seem to have been made is not putting in a comment (Annex C) noting
the intent!

> I note that my old Fortran77 code which is Standard-conforming except for
> its use of the dollar descriptor works well on all f90 compilers I have
> access to here, with the exception NAGware f90 and NAGace f95.  If I

Unless of course you try writing the results to a file (or piping it),
in which case you get different results from VMS (which treats "$"
roughly as you describe - viz separate records) and Unix (which treats
"$" roughly as I described - viz partial records).

It would seem a lot easier to get the few vendors which don't get this
one right to do so.

> change the write from using a $ decriptor to using advance="no" the
> program works on some f90 systems, but no others, because of variations in
> the way that they flush after partial records.  This is a serious
> nuisance in my efforts to convert old software to conform to new
> standards.
> 
> > And as you yourself note, the "$" descriptor is even less well-defined than
> > non-advancing i/o.
> 
> Yes, I was proposing that it _should_ be properly defined in a future
> Fortran Standard.

Well, if you could come up with the words to define "$" to do the
right thing, they could be applied to non-advancing i/o.  But since
the standard never has defined how physical devices handle i/o, you
would probably just be straight back to the "quality of
implementation" issue; relying on a comment (e.g. in Annex C) to
explain what ought to happen.

Anyway, it seems a lot easier to me (and a lot quicker as well) to
convince a small number of vendors to "do the right thing" here than
it would be to get a large number of people to agree on changing the
standard (in 2010 perhaps!?!).

Cheers,
-- 
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
                           ([log in to unmask])




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%