From: Richard Maine <maine@altair.dfrc.nasa.gov>
Newsgroups: comp.lang.fortran
Subject: Re: carriage control in g77
Date: 07 Jun 2000 13:37:49 -0700

Simon Huang <s1m0n@saintmail.net> writes:

> hi, i am trying to learn fortran77 with a book from the late 80s and
> using the gnu g77 compiler. however, i've notice that g77 is not
> treating my carriage control character, eg. '+', '1', '0', etc as the
> book mention. is it because of new language definition? thanks alot

No.  Its because it has always been processor-dependent what files
carriage control got applied to.  In the "old days" carriage control
was done by the physical printer.  This wasn't actually part of the
Fortran compiler.  Some of "us" think that it should have never been
in the Fortran standard, because it really had nothing to do with
Fortran.  It was just describing how printers (of the time) worked.
You'd get the same effect if you sent the printer a file made by
Cobol, a text editor, or anything else.  And if you did anything
other than print the file, the carriage control characters were
just ordinary characters in the file.

That section of the standard was really just parroting the ASA standard
for printer carriage control.  (No, I don't offhand know where to find
the ASA standard.  You might think it would have been referenced in the
Fortran standard.  But you'd be wrong...I just checked back in the F77
standard, but it doesn't seem to be there).

These days, few printers still follow the ASA standard.  (There are
probably still mainframe line-printers that do, but that's a pretty
small portion of the Fortran market any more).  Many unix systems have
a utility called asa (the name is no coincidence) or fpr (as in
Fortran print) that will filter a file that has ASA carriage control
characters and put out a result that uses ASCII control characters.
You can use that as part of the "print filter" for files with ASA
carriage control if you like.

At last week's J3 meeting, it was voted to remove the ASA carriage
control stuff from the draft of the f2k standard.  As noted above,
this stuff never really did have anything to do with Fortran.  It was
just a description of (now largely obsolete) printers.  Its comparable
to ANSI screen control stuff.

Removing this small section from the standard won't actually effect
anything the vendors do anyway.  Most vendors already do nothing
about ASA carriage control (i.e. the processor-dependent set of files
that it applies to is empty - either that or they could just count
running asa as part of the "printing" process) and they will presumably
continue to do the same thing (i.e. nothing).  Those few vendors that
actually do something for carriage control will presumably still continue
to do so.  The standard doesn't prohibit them from having a device that
does "funny" things with column 1 any more than the standard prohibits
them from having a terminal device that does "funny" things to character
sequences beginning with an escape character (as in ANSI screen control).

The main effects I envision are

1. Those (few) vendors that actively do something with column 1 are more
   likely to provide at least an option to turn it off (if they don't
   already).

2. Users will be less prone to incorrectly think that using carriage control
   will necessarily have the effect described in the standard.  Of course, it
   will take a *LONG* time for this result because we'll sill have users
   reading the older standards and books and getting confused by them.

--
Richard Maine
maine@altair.dfrc.nasa.gov

From: Richard Maine <maine@altair.dfrc.nasa.gov>
Newsgroups: comp.lang.fortran
Subject: Re: tab edit descriptors and nonadvancing I/O
Date: 14 Jun 2000 09:41:32 -0700

Dick Hendrickson <dick.hendrickson@att.net> writes:

> "Craig T. Dedo" wrote:
> >     At the J3 meeting the week of May 29 - June 2, J3 voted to delete the ASA
> > carriage control from Fortran 2000.
...

> So, some processors can select some processor dependent set of units
> and and say they do NOT have the property of "NOT special casing
> column 1 for carriage control".  Then any statement that refers to
> those units must be aware of the ASA stuff.  (Unless I messed up on
> the double negatives and I needed a triple negative, ;-} )

I think you have it right.  But I don't think one needs to be that
obscure to get the same conclusion.  The standard just doesn't address at
all what it means at the physical level to "write to a file".  Any
correlation between writing characters to a file and ink appearing on
paper, for example, is completely up to the processor.  The processor
might do ASA carriage control with the first character of each line.
It might interpret the file as HP printer control language and do
"strange" things with certain character sequences that include the
escape control character.  It might interpret the file as postscript
commands and do all kinds of complicated things to it.  These are all
very real and likely things - I'm not having to make up obscure
theoretical situations.  All of these examples are for "printers".
Simillar comments apply to what might happen for output to a "file"
that corresponded to a terminal, or to any other physical device.

That's part of why I voted in favor of getting rid of that section.
It never really did say that anything in particular would happen
for any file in particular.  It just said that the processor might
do carriage control processing on some files.  Or it might not.
Or it might do some other kind of processing.  All of which is true
with or without that section in the standard.  So the section didn't
really add anything.....except for confusion...it added plenty of that.

--
Richard Maine
maine@altair.dfrc.nasa.gov