Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Removing the first whitespace in list-directed output lines
1,211 views
Skip to first unread message
spectrum
Jun 18, 2019, 11:31:02 AM6/18/19
to
Hello,
I often use list-directed output with asterisk (e.g. "print *") for simple/minimum
output for the standard output (i.e., not for writing tabular data or *.dat files etc).
However, the output obtained with asterisk always has one additional space
at the beginning of each line, which makes the output less neat...
For example, this code
program main
implicit none
integer i
i = 100
print *, "i = ", i
write(6,*) "i = ", i
write(6,"(a,i0)") "i = ", i
end
gives the output (with gfortran-8.2 on Mac):
i = 100
i = 100
i = 100
(Here, please note that there is one whitespace in the first two lines, while not
in the third line.)
Although my understanding of "*" is to ask the compiler to use her "nice" format of choice
(so the user cannot complain...). But I'm still wondering:
* Is there possibly some way to delete this whitespace somehow when
using list-directed output? Possibly, is there a hidden environmental
variable that can be used to control such automatic formatting...?
* What is the rationale of keeping this whitespace in 2019? I remember having read
some story about this white space (related to old line printers (?)).
I.e., is it retained for keeping backward compatibility with old line printers...?
I often use list-directed output with asterisk (e.g. "print *") for simple/minimum
output for the standard output (i.e., not for writing tabular data or *.dat files etc).
However, the output obtained with asterisk always has one additional space
at the beginning of each line, which makes the output less neat...
For example, this code
program main
implicit none
integer i
i = 100
print *, "i = ", i
write(6,*) "i = ", i
write(6,"(a,i0)") "i = ", i
end
gives the output (with gfortran-8.2 on Mac):
i = 100
i = 100
i = 100
(Here, please note that there is one whitespace in the first two lines, while not
in the third line.)
Although my understanding of "*" is to ask the compiler to use her "nice" format of choice
(so the user cannot complain...). But I'm still wondering:
* Is there possibly some way to delete this whitespace somehow when
using list-directed output? Possibly, is there a hidden environmental
variable that can be used to control such automatic formatting...?
* What is the rationale of keeping this whitespace in 2019? I remember having read
some story about this white space (related to old line printers (?)).
I.e., is it retained for keeping backward compatibility with old line printers...?
steve kargl
Jun 18, 2019, 1:13:25 PM6/18/19
to
spectrum wrote:
>
> Although my understanding of "*" is to ask the compiler to use her "nice" format of choice
> (so the user cannot complain...). But I'm still wondering:
>
> * Is there possibly some way to delete this whitespace somehow when
> using list-directed output? Possibly, is there a hidden environmental
> variable that can be used to control such automatic formatting...?
>
> * What is the rationale of keeping this whitespace in 2019? I remember having read
> some story about this white space (related to old line printers (?)).
> I.e., is it retained for keeping backward compatibility with old line printers...?
The Fortran standard requires the blank. From 2018, 13.10.4 List-directed output
>
> Although my understanding of "*" is to ask the compiler to use her "nice" format of choice
> (so the user cannot complain...). But I'm still wondering:
>
> * Is there possibly some way to delete this whitespace somehow when
> using list-directed output? Possibly, is there a hidden environmental
> variable that can be used to control such automatic formatting...?
>
> * What is the rationale of keeping this whitespace in 2019? I remember having read
> some story about this white space (related to old line printers (?)).
> I.e., is it retained for keeping backward compatibility with old line printers...?
(page 277):
Except for new records created by explicit formatting within a
defined output procedure or by continuation of delimited character
sequences, each output record begins with a blank character.
--
steve
Steve Lionel
Jun 18, 2019, 1:30:47 PM6/18/19
to
On 6/18/2019 1:13 PM, steve kargl wrote:
>> * What is the rationale of keeping this whitespace in 2019? I remember having read
>> some story about this white space (related to old line printers (?)).
>> I.e., is it retained for keeping backward compatibility with old line printers...?
>
> The Fortran standard requires the blank. From 2018, 13.10.4 List-directed output
> (page 277):
>
> Except for new records created by explicit formatting within a
> defined output procedure or by continuation of delimited character
> sequences, each output record begins with a blank character.
The blank is there for use with "Fortran carriage control", indeed
>> * What is the rationale of keeping this whitespace in 2019? I remember having read
>> some story about this white space (related to old line printers (?)).
>> I.e., is it retained for keeping backward compatibility with old line printers...?
>
> The Fortran standard requires the blank. From 2018, 13.10.4 List-directed output
> (page 277):
>
> Except for new records created by explicit formatting within a
> defined output procedure or by continuation of delimited character
> sequences, each output record begins with a blank character.
created for use with line printers, but no longer part of the language.
I certainly understand that it is now more annoying than useful, though
one might argue that if you care this much about formatting you should
use explicit formats instead, since list-directed gives the processor
significant flexibility in what the output looks like. I would probably
not be in favor of changing it for this reason (and if it was made
optional or removed, we'd need a way to specify the leading blank should
remain - not worth it in my opinion.)
--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran
FortranFan
Jun 18, 2019, 1:47:54 PM6/18/19
to
On Tuesday, June 18, 2019 at 1:30:47 PM UTC-4, Steve Lionel wrote:
> .. though
Yes, also considering one can have a default "general" format and use it with PRINT statements to reasonably mimic the asterisk-based output:
..
character(len=*), parameter :: g = "(*(g0))"
..
print g, "i = ", i
..
it is difficult to see much energy behind any change to this legacy behind the blank with list-directed output in the language.
However I wonder if the standard can consider introducing one (or more) sets of predefined formats (like the "g" above; of course the label can be something different, say another keyboard character or a name such as 'fmtg', etc.) in, say, ISO_FORTRAN_ENV or some such intrinsic module?
> .. though
> one might argue that if you care this much about formatting you should
> use explicit formats instead, since list-directed gives the processor
> significant flexibility in what the output looks like. ..
> use explicit formats instead, since list-directed gives the processor
Yes, also considering one can have a default "general" format and use it with PRINT statements to reasonably mimic the asterisk-based output:
..
character(len=*), parameter :: g = "(*(g0))"
..
print g, "i = ", i
..
it is difficult to see much energy behind any change to this legacy behind the blank with list-directed output in the language.
However I wonder if the standard can consider introducing one (or more) sets of predefined formats (like the "g" above; of course the label can be something different, say another keyboard character or a name such as 'fmtg', etc.) in, say, ISO_FORTRAN_ENV or some such intrinsic module?
spectrum
Jun 18, 2019, 4:18:26 PM6/18/19
to
Dear all,
Thanks very much for various info! As for the standard, I did not expect that
this first blank (whitespace) was explicitly described there, so a bit surprising to me...
(I imagined that it is a very common or "de-fact standard" behavior of many compilers
for backward compatibility.)
And I agree that the effort/energy for changing this behavior is probably not very worth
while (as compared to other new or more important features).
Indeed, one of the reasons why this first blank becomes a bit annoying (to me) is just
my use of Emacs. In the shell mode of Emacs, output lines like
foo:
warning: blah blah
are displayed in vivid color (to get attention), while output lines with leading blanks like
foo:
warning: blah
are displayed in white (= normal text color). So, even if I wanted to write
warning: array X is empty!
it is displayed in white with "print *", so doesn't look very much like warning... XD
------
RE the "g0" format, I have never used it up to now,
> character(len=*), parameter :: g = "(*(g0))"
Because I had a macro like
#define _put_ write(6,*)
I changed it to
#define _put_ write(6,'(*(g0,2x))')
which works almost perfectly (i.e. no first blank).
# The reason for using unit 6 is minor and not relevant here...
(just for dealing output from slave nodes in MPI).
Anyway, this "g0" seems to solve my problem above. Thanks very much!
Thanks very much for various info! As for the standard, I did not expect that
this first blank (whitespace) was explicitly described there, so a bit surprising to me...
(I imagined that it is a very common or "de-fact standard" behavior of many compilers
for backward compatibility.)
And I agree that the effort/energy for changing this behavior is probably not very worth
while (as compared to other new or more important features).
Indeed, one of the reasons why this first blank becomes a bit annoying (to me) is just
my use of Emacs. In the shell mode of Emacs, output lines like
foo:
warning: blah blah
are displayed in vivid color (to get attention), while output lines with leading blanks like
foo:
warning: blah
are displayed in white (= normal text color). So, even if I wanted to write
warning: array X is empty!
it is displayed in white with "print *", so doesn't look very much like warning... XD
------
RE the "g0" format, I have never used it up to now,
> character(len=*), parameter :: g = "(*(g0))"
> print g, "i = ", i
so played with it for a while. Then it does seem to be very useful!
Because I had a macro like
#define _put_ write(6,*)
I changed it to
#define _put_ write(6,'(*(g0,2x))')
which works almost perfectly (i.e. no first blank).
# The reason for using unit 6 is minor and not relevant here...
(just for dealing output from slave nodes in MPI).
Anyway, this "g0" seems to solve my problem above. Thanks very much!
robin....@gmail.com
Jun 19, 2019, 12:08:11 AM6/19/19
to
Some mechanical serial printers of speeds up to 30 characters/second
benefit from the extra blank because of the length of time it takes
to perform a carriage return and a page throw.
Ron Shepard
Jun 19, 2019, 2:32:03 AM6/19/19
to
On 6/18/19 10:31 AM, spectrum wrote:
> However, the output obtained with asterisk always has one additional space
> at the beginning of each line, which makes the output less neat...
Before the (modern) ANSI standards organization (formed from other
> However, the output obtained with asterisk always has one additional space
> at the beginning of each line, which makes the output less neat...
organizations in 1969) where was ASA (American Standards Association).
This is not a government agency, it is a private non-profit
organization. They defined a print file format that used the first
character of each line to determine how it should be printed. A blank '
', meant to advance one line before printing. Some of the other
possibilities were '+' which meant to not advance at all but to
overprint the previous line with the new one, '0' advance two lines, '-'
advance three lines, and '1' advance to the next page. These characters
were not printed in the output, they just controlled the printer carriage.
The early Fortran versions (starting with II, I think) used that
standard convention. In order to avoid anything special or unexpected on
list-directed i/o, it always wrote the leading space. It was not
uncommon in the 1960s and even the 1970s to print a file from a fortran
program and instead of getting a few pages of output back, you would get
a stack of paper an inch thick. The reason is that you would forget to
add that leading space before printing, and the various combinations of
numbers and '-' signs in the first column would cause the paper to spin
through the printer, mostly blank, with only a few lines per page.
With this printer convention, list directed i/o would have been
practically useless without that leading space. This behavior was
standardized in the fortran standard, and it apparently has survived
some 50 or 60 years to the present day. It is sometimes called "fortran
carriage control", but that isn't really correct, it is really ASA
carriage control, adopted into fortran.
Many computers have a utility (e.g. asa in unix) that takes such a file
and converts it into ASCII characters. The ASCII convention is to embed
various nonprinting characters (denoted CR, LF, FF, VT) into the file to
control the printer carriage.
$.02 -Ron Shepard
Phillip Helbig (undress to reply)
Jun 19, 2019, 2:41:23 AM6/19/19
to
In article <AFkOE.137601$3T5....@fx45.iad>, Ron Shepard
printer to cut the page at that position. :-)
> '0' advance two lines, '-'
> advance three lines,
I don't think that the "-" was ever standard.
<nos...@nowhere.org> writes:
> On 6/18/19 10:31 AM, spectrum wrote:
> > However, the output obtained with asterisk always has one additional space
> > at the beginning of each line, which makes the output less neat...
>
> Before the (modern) ANSI standards organization (formed from other
> organizations in 1969) where was ASA (American Standards Association).
> This is not a government agency, it is a private non-profit
> organization. They defined a print file format that used the first
> character of each line to determine how it should be printed. A blank '
> ', meant to advance one line before printing. Some of the other
> possibilities were '+' which meant to not advance at all but to
> overprint the previous line with the new one,
There are tales of people using the + descriptor in a loop, to cause the
> On 6/18/19 10:31 AM, spectrum wrote:
> > However, the output obtained with asterisk always has one additional space
> > at the beginning of each line, which makes the output less neat...
>
> Before the (modern) ANSI standards organization (formed from other
> organizations in 1969) where was ASA (American Standards Association).
> This is not a government agency, it is a private non-profit
> organization. They defined a print file format that used the first
> character of each line to determine how it should be printed. A blank '
> ', meant to advance one line before printing. Some of the other
> possibilities were '+' which meant to not advance at all but to
> overprint the previous line with the new one,
printer to cut the page at that position. :-)
> '0' advance two lines, '-'
> advance three lines,
michael...@compuserve.com
Jun 19, 2019, 4:21:56 AM6/19/19
to
On Wednesday, 19 June 2019 08:41:23 UTC+2, Phillip Helbig (undress to reply) wrote:
>
> I don't think that the "-" was ever standard.
It wasn't but, for the sake of completeness, I note that the complete rule is that for each record produced by BOTH list-directed or namelist output, the first character is blank UNLESS it is the continuation of a delimited character constant.
>
> I don't think that the "-" was ever standard.
Regards,
Mike Metcalf
robin....@gmail.com
Jun 19, 2019, 8:23:35 AM6/19/19
to
On Wednesday, June 19, 2019 at 4:41:23 PM UTC+10, Phillip Helbig (undress to reply) wrote:
If the paper were severed at the print station, the paper would jam
on attempting the next line feed.
> In article <A......@fx45.iad>, Ron Shepard <nos...@nowhere.org> writes:
>
> > On 6/18/19 10:31 AM, spectrum wrote:
> > > However, the output obtained with asterisk always has one additional space
> > > at the beginning of each line, which makes the output less neat...
> >
> > Before the (modern) ANSI standards organization (formed from other
> > organizations in 1969) where was ASA (American Standards Association).
> > This is not a government agency, it is a private non-profit
> > organization. They defined a print file format that used the first
> > character of each line to determine how it should be printed. A blank '
> > ', meant to advance one line before printing. Some of the other
> > possibilities were '+' which meant to not advance at all but to
> > overprint the previous line with the new one,
>
> There are tales of people using the + descriptor in a loop, to cause the
> printer to cut the page at that position. :-)
Are you sure?
>
> > On 6/18/19 10:31 AM, spectrum wrote:
> > > However, the output obtained with asterisk always has one additional space
> > > at the beginning of each line, which makes the output less neat...
> >
> > Before the (modern) ANSI standards organization (formed from other
> > organizations in 1969) where was ASA (American Standards Association).
> > This is not a government agency, it is a private non-profit
> > organization. They defined a print file format that used the first
> > character of each line to determine how it should be printed. A blank '
> > ', meant to advance one line before printing. Some of the other
> > possibilities were '+' which meant to not advance at all but to
> > overprint the previous line with the new one,
>
> There are tales of people using the + descriptor in a loop, to cause the
> printer to cut the page at that position. :-)
If the paper were severed at the print station, the paper would jam
on attempting the next line feed.
robin....@gmail.com
Jun 19, 2019, 9:38:15 AM6/19/19
to
On Wednesday, June 19, 2019 at 4:32:03 PM UTC+10, Ron Shepard wrote:
> On 6/18/19 10:31 AM, spectrum wrote:
> > However, the output obtained with asterisk always has one additional space
> > at the beginning of each line, which makes the output less neat...
>
> Before the (modern) ANSI standards organization (formed from other
> organizations in 1969) where was ASA (American Standards Association).
> This is not a government agency, it is a private non-profit
> organization. They defined a print file format that used the first
> character of each line to determine how it should be printed. A blank '
> ', meant to advance one line before printing. Some of the other
> possibilities were '+' which meant to not advance at all but to
> overprint the previous line with the new one, '0' advance two lines, '-'
> advance three lines, and '1' advance to the next page. These characters
> were not printed in the output, they just controlled the printer carriage.
With the advent of line printers (when was the first one made?),
> On 6/18/19 10:31 AM, spectrum wrote:
> > However, the output obtained with asterisk always has one additional space
> > at the beginning of each line, which makes the output less neat...
>
> Before the (modern) ANSI standards organization (formed from other
> organizations in 1969) where was ASA (American Standards Association).
> This is not a government agency, it is a private non-profit
> organization. They defined a print file format that used the first
> character of each line to determine how it should be printed. A blank '
> ', meant to advance one line before printing. Some of the other
> possibilities were '+' which meant to not advance at all but to
> overprint the previous line with the new one, '0' advance two lines, '-'
> advance three lines, and '1' advance to the next page. These characters
> were not printed in the output, they just controlled the printer carriage.
a convenient means of directing the printer to move the paper
was to use the first character of a line of data.
Possibly this convention arose from the need to print data from
a file, instead of directly from the computer itself.
(Under the latter scenario, signal wires from the computer hardware
could direct paper movement for the current print line.)
> The early Fortran versions (starting with II, I think) used that
> standard convention. In order to avoid anything special or unexpected on
> list-directed i/o, it always wrote the leading space. It was not
> uncommon in the 1960s and even the 1970s to print a file from a fortran
> program and instead of getting a few pages of output back, you would get
> a stack of paper an inch thick. The reason is that you would forget to
> add that leading space before printing, and the various combinations of
> numbers and '-' signs in the first column would cause the paper to spin
> through the printer, mostly blank, with only a few lines per page.
>
> With this printer convention, list directed i/o would have been
> practically useless without that leading space. This behavior was
> standardized in the fortran standard, and it apparently has survived
> some 50 or 60 years to the present day. It is sometimes called "fortran
> carriage control", but that isn't really correct, it is really ASA
> carriage control, adopted into fortran.
to the line printer is used to control paper movement.
However, that character is invisible to the programmer.
Paper movement is controlled by the keywords PAGE, SKIP, and LINE
[with SKIP (n) and LINE (n) specifying how many lines to skip,
or on which line of the page to resume printing, respectively].
It doesn't matter whether output is being directed to a line
printer or to a serial printer, the same keywords produce the
required effect.
That's the way it worked from the beginning (1965).
Ron Shepard
Jun 19, 2019, 10:46:21 AM6/19/19
to
On 6/19/19 1:41 AM, Phillip Helbig (undress to reply) wrote:
> In article <AFkOE.137601$3T5....@fx45.iad>, Ron Shepard
> <nos...@nowhere.org> writes:
[...]>>They defined a print file format that used the first
> In article <AFkOE.137601$3T5....@fx45.iad>, Ron Shepard
> <nos...@nowhere.org> writes:
>> character of each line to determine how it should be printed. A blank '
>> ', meant to advance one line before printing. Some of the other
>> possibilities were '+' which meant to not advance at all but to
>> overprint the previous line with the new one,
>
> There are tales of people using the + descriptor in a loop, to cause the
> printer to cut the page at that position. :-)
>
>> '0' advance two lines, '-'
>> advance three lines,
>
> I don't think that the "-" was ever standard.
Here is a link that has more detail about this standard.
>> ', meant to advance one line before printing. Some of the other
>> possibilities were '+' which meant to not advance at all but to
>> overprint the previous line with the new one,
>
> There are tales of people using the + descriptor in a loop, to cause the
> printer to cut the page at that position. :-)
>
>> '0' advance two lines, '-'
>> advance three lines,
>
> I don't think that the "-" was ever standard.
https://en.wikipedia.org/wiki/ASA_carriage_control_characters
$.02 -Ron Shepard
Ron Shepard
Jun 19, 2019, 10:53:49 AM6/19/19
to
On 6/19/19 8:38 AM, robin....@gmail.com wrote:
> With the advent of line printers (when was the first one made?),
> a convenient means of directing the printer to move the paper
> was to use the first character of a line of data.
> Possibly this convention arose from the need to print data from
> a file, instead of directly from the computer itself.
> (Under the latter scenario, signal wires from the computer hardware
> could direct paper movement for the current print line.)
These two conventions are sometimes called "in-band" and "out-of-band"
> With the advent of line printers (when was the first one made?),
> a convenient means of directing the printer to move the paper
> was to use the first character of a line of data.
> Possibly this convention arose from the need to print data from
> a file, instead of directly from the computer itself.
> (Under the latter scenario, signal wires from the computer hardware
> could direct paper movement for the current print line.)
signaling. Both ASA and later ASCII are in-band conventions, where the
carriage control signals are in the same data connection as the data to
be printed.
$.02 -Ron Shepard
ga...@u.washington.edu
Jun 22, 2019, 2:26:46 AM6/22/19
to
On Wednesday, June 19, 2019 at 6:38:15 AM UTC-7, robin...@gmail.com wrote:
(snip)
> However, that character is invisible to the programmer.
> Paper movement is controlled by the keywords PAGE, SKIP, and LINE
> [with SKIP (n) and LINE (n) specifying how many lines to skip,
> or on which line of the page to resume printing, respectively].
> It doesn't matter whether output is being directed to a line
> printer or to a serial printer, the same keywords produce the
> required effect.
> That's the way it worked from the beginning (1965).
OS/360 allows for two types of carriage control, in addition
to no carriage control. Many programs use ASA carriage control,
with the letter A appended to RECFM (record format), such as FBA.
(Fixed Blocked with Asa carriage control, common with Fortran.)
Some programs, mostly IBM utilities use M (machine) carriage
control, where the characters are the actual channel commands.
These differ from ASA, in that carriage motion happens after,
not before, the line. I believe spooling systems convert
all to M before they get spooled, and then sent to the printer.
If you don't want them, it is a simple change to the JCL.
(snip)
> However, that character is invisible to the programmer.
> Paper movement is controlled by the keywords PAGE, SKIP, and LINE
> [with SKIP (n) and LINE (n) specifying how many lines to skip,
> or on which line of the page to resume printing, respectively].
> It doesn't matter whether output is being directed to a line
> printer or to a serial printer, the same keywords produce the
> required effect.
> That's the way it worked from the beginning (1965).
to no carriage control. Many programs use ASA carriage control,
with the letter A appended to RECFM (record format), such as FBA.
(Fixed Blocked with Asa carriage control, common with Fortran.)
Some programs, mostly IBM utilities use M (machine) carriage
control, where the characters are the actual channel commands.
These differ from ASA, in that carriage motion happens after,
not before, the line. I believe spooling systems convert
all to M before they get spooled, and then sent to the printer.
If you don't want them, it is a simple change to the JCL.
ga...@u.washington.edu
Jun 22, 2019, 2:32:30 AM6/22/19
to
On Wednesday, June 19, 2019 at 7:53:49 AM UTC-7, Ron Shepard wrote:
(snip)
> These two conventions are sometimes called "in-band" and "out-of-band"
> signaling. Both ASA and later ASCII are in-band conventions, where the
> carriage control signals are in the same data connection as the data to
> be printed.
Well, it is Fortran that traditionally made CC in-band.
As noted above, it is out of band in PL/I, Java, and many other languages,
but often converted to in-band by the I/O library.
(snip)
> These two conventions are sometimes called "in-band" and "out-of-band"
> signaling. Both ASA and later ASCII are in-band conventions, where the
> carriage control signals are in the same data connection as the data to
> be printed.
As noted above, it is out of band in PL/I, Java, and many other languages,
but often converted to in-band by the I/O library.
robin....@gmail.com
Jun 22, 2019, 4:59:04 AM6/22/19
to
On Saturday, June 22, 2019 at 4:32:30 PM UTC+10, ga...@u.washington.edu wrote:
> On Wednesday, June 19, 2019 at 7:53:49 AM UTC-7, Ron Shepard wrote:
>
> (snip)
>
> > These two conventions are sometimes called "in-band" and "out-of-band"
> > signaling. Both ASA and later ASCII are in-band conventions, where the
> > carriage control signals are in the same data connection as the data to
> > be printed.
>
> Well, it is Fortran that traditionally made CC in-band.
>
> As noted above, it is out of band in PL/I,
No, PL/I is the same as FORTRAN on OS/360, i.e. with line printers.
> On Wednesday, June 19, 2019 at 7:53:49 AM UTC-7, Ron Shepard wrote:
>
> (snip)
>
> > These two conventions are sometimes called "in-band" and "out-of-band"
> > signaling. Both ASA and later ASCII are in-band conventions, where the
> > carriage control signals are in the same data connection as the data to
> > be printed.
>
> Well, it is Fortran that traditionally made CC in-band.
>
> As noted above, it is out of band in PL/I,
I already stated that on a terminal, the same
output options (LIST, PAGE, LINE) have similar effect
as on line printers.
dave_th...@comcast.net
Aug 17, 2019, 11:27:47 AM8/17/19
to
Java has special methods like PrintWriter,println for nextline only
(not skipN channelN verttab formfeed etc), but they are specified as
identical to outputting the character(s) from sysprop line.separator,
which also must work and IME is as common, including the
in-between-ish form printf("%n")
I don't know any out-of-band carriage control that handled TTY37's
half-up and half-down for superscript and subscript :-)
You also wrote:
> it is a simple change to the JCL.
urba...@comcast.net
Aug 17, 2019, 8:08:27 PM8/17/19
to
Great that "g0" meets your needs, but for completeness note a caveat -- complex values are rendered very differently when using g0 than when using list-directed output, and options like DELIM='QUOTE' are not allowed when formats are specified, unfortunately. This makes it non-trivial to write CSV values for example (which really are not standardized anyway), even though you can do simple
numeric values in CSV format with PRINT '(*(G0:,","))', value(s). It would indeed be a nice extension to have something like DELIM='CSV' which would quote strings and start in column one and be guaranteed to write just one line
per WRITE(), or DELIM='MINIMAL' to start in column one and only place on space between values, somewhat like the suggestion to have pre-defined standard formats. It sounds like you already have your solution for your particular case but examine the following output to see that the output from list-directed output and from "g0" can have big differences other than just whitespace..
program g0
character(len=*),parameter :: g='(*(g0))'
character(len=*),parameter :: csv='(*(g0:,","))'
character(len=*),parameter :: spaces='(*(g0:," "))'
print g, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print g, .true., (123.456, 789.012), 'Gee!'
print *
print csv, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print csv, .true., (123.456, 789.012), 'Gee! "CSV"'
print *
print spaces, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print spaces, .true., (123.456, 789.012), 'Gee! "SPACES"'
print *
write(*, *, delim='none')10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
write(*, *, delim='none').true., (123.456, 789.012), 'Gee!'
print *
write(*, *, delim='quote')10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
write(*, *, delim='quote').true., (123.456, 789.012), 'Gee! "QUOTE"'
end
101234.567029876543210.12345700.17976931348623157E+309
T123.456001789.012024Gee!
10,1234.56702,9876543210.1234570,0.17976931348623157E+309
T,123.456001,789.012024,Gee! "CSV"
10 1234.56702 9876543210.1234570 0.17976931348623157E+309
T 123.456001 789.012024 Gee! "SPACES"
10 1234.56702 9876543210.1234570 1.7976931348623157E+308
T (123.456001,789.012024) Gee!
10 1234.56702 9876543210.1234570 1.7976931348623157E+308
T (123.456001,789.012024) "Gee! ""QUOTE"""
numeric values in CSV format with PRINT '(*(G0:,","))', value(s). It would indeed be a nice extension to have something like DELIM='CSV' which would quote strings and start in column one and be guaranteed to write just one line
per WRITE(), or DELIM='MINIMAL' to start in column one and only place on space between values, somewhat like the suggestion to have pre-defined standard formats. It sounds like you already have your solution for your particular case but examine the following output to see that the output from list-directed output and from "g0" can have big differences other than just whitespace..
program g0
character(len=*),parameter :: g='(*(g0))'
character(len=*),parameter :: csv='(*(g0:,","))'
character(len=*),parameter :: spaces='(*(g0:," "))'
print g, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print g, .true., (123.456, 789.012), 'Gee!'
print *
print csv, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print csv, .true., (123.456, 789.012), 'Gee! "CSV"'
print *
print spaces, 10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
print spaces, .true., (123.456, 789.012), 'Gee! "SPACES"'
print *
write(*, *, delim='none')10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
write(*, *, delim='none').true., (123.456, 789.012), 'Gee!'
print *
write(*, *, delim='quote')10, 1234.567, 9876543210.123456789d0, huge(1.0d0)
write(*, *, delim='quote').true., (123.456, 789.012), 'Gee! "QUOTE"'
end
101234.567029876543210.12345700.17976931348623157E+309
T123.456001789.012024Gee!
10,1234.56702,9876543210.1234570,0.17976931348623157E+309
T,123.456001,789.012024,Gee! "CSV"
10 1234.56702 9876543210.1234570 0.17976931348623157E+309
T 123.456001 789.012024 Gee! "SPACES"
10 1234.56702 9876543210.1234570 1.7976931348623157E+308
T (123.456001,789.012024) Gee!
10 1234.56702 9876543210.1234570 1.7976931348623157E+308
T (123.456001,789.012024) "Gee! ""QUOTE"""
Clive Page
Aug 18, 2019, 5:17:26 AM8/18/19
to
On 18/08/2019 01:08, urba...@comcast.net wrote:
> Great that "g0" meets your needs, but for completeness note a caveat -- complex values are rendered very differently when using g0 than when using list-directed output, and options like DELIM='QUOTE' are not allowed when formats are specified, unfortunately. This makes it non-trivial to write CSV values for example (which really are not standardized anyway), even though you can do simple
I agree that g format isn't really a replacement for list-directed output. And I do find list-directed output very handy when testing a program to produce quick and easy output of intermediate results. But the rules, especially, the required initial space, can be annoying.
> Great that "g0" meets your needs, but for completeness note a caveat -- complex values are rendered very differently when using g0 than when using list-directed output, and options like DELIM='QUOTE' are not allowed when formats are specified, unfortunately. This makes it non-trivial to write CSV values for example (which really are not standardized anyway), even though you can do simple
Maybe we could have a modern replacement without as many 1970s era restrictions by using a colon as the format designator instead of the asterisk:
WRITE(UNIT=unit, FMT=:) whatever
--
Clive Page
ga...@u.washington.edu
Aug 18, 2019, 8:34:00 AM8/18/19
to
On Sunday, August 18, 2019 at 2:17:26 AM UTC-7, Clive Page wrote:
(snip)
> I agree that g format isn't really a replacement for list-directed
> output. And I do find list-directed output very handy when testing
> a program to produce quick and easy output of intermediate results.
> But the rules, especially, the required initial space, can be annoying.
While I do agree that the reason for the initial blank is to avoid
problems with carriage control, I disagree that it wouldn't be there
without CC.
The output should look at least slightly nice to the reader.
For example, printing the data values without any other characters,
numeric values packed adjacent, would be horrible. Maybe just a
comma between, but it still doesn't look all that nice.
Some amount of space before and/or after the numeric (or non-numeric)
list items makes it look nicer.
(snip)
> I agree that g format isn't really a replacement for list-directed
> output. And I do find list-directed output very handy when testing
> a program to produce quick and easy output of intermediate results.
> But the rules, especially, the required initial space, can be annoying.
problems with carriage control, I disagree that it wouldn't be there
without CC.
The output should look at least slightly nice to the reader.
For example, printing the data values without any other characters,
numeric values packed adjacent, would be horrible. Maybe just a
comma between, but it still doesn't look all that nice.
Some amount of space before and/or after the numeric (or non-numeric)
list items makes it look nicer.
Gary Scott
Aug 18, 2019, 12:18:59 PM8/18/19
to
card. : doesn't quite work as a replacement for me aesthetically given
its other uses in fortran. But I like the idea of being able to
suppress the leading space if desired, although it doesn't bother me
much that it is present most of the time.
Gary Scott
Aug 18, 2019, 12:36:50 PM8/18/19
to
formatting expectations rather than just suppressing the leading control
character.
robin....@gmail.com
Aug 18, 2019, 11:05:22 PM8/18/19
to
On Monday, August 19, 2019 at 2:18:59 AM UTC+10, Gary Scott wrote:
> On 8/18/2019 4:17 AM, Clive Page wrote:
> On 8/18/2019 4:17 AM, Clive Page wrote:
the leading space was required for carriage control of the printer.
If it was omitted, the leading character of the a number would disappear
without warning.
These days, it is largely superfluous.
The leading space in list-directed O/P is of no consequence.
It doesn't need yet more control codes to suppress it.
If it works, don't fix it.
ga...@u.washington.edu
Aug 19, 2019, 3:15:21 AM8/19/19
to
On Sunday, August 18, 2019 at 9:36:50 AM UTC-7, Gary Scott wrote:
(snip)
> I guess I could get used to it if ":" implied a well defined set of
> formatting expectations rather than just suppressing the leading control
> character.
From the description in the standard of list-directed output:
"The form of the values produced is the same as that required for
input, except as noted otherwise. With the exception of adjacent
undelimited character sequences, the values are separated by one
or more blanks or by a comma, or a semicolon if the decimal edit
mode is COMMA, optionally preceded by one or more blanks and
optionally followed by one or more blanks."
Note that besides the initial blank, believed to be for carriage
control reasons, data items may be preceded or followed by blanks.
Even if the blank that started this thread isn't required, the
standard still allows blanks before and after list items.
Note, though, that some languages allow one to specify how
output is produced. AWK has the OFMT and CONVFMT variables which
specify the format use for print statements, and for conversion
of numeric values to character string values. (The format values
could include one or more blanks.)
If one wanted to do something different from the current form,
one should allow a general specification of output values,
including blanks before and after list items, and any
non-blank separator.
(snip)
> I guess I could get used to it if ":" implied a well defined set of
> formatting expectations rather than just suppressing the leading control
> character.
"The form of the values produced is the same as that required for
input, except as noted otherwise. With the exception of adjacent
undelimited character sequences, the values are separated by one
or more blanks or by a comma, or a semicolon if the decimal edit
mode is COMMA, optionally preceded by one or more blanks and
optionally followed by one or more blanks."
Note that besides the initial blank, believed to be for carriage
control reasons, data items may be preceded or followed by blanks.
Even if the blank that started this thread isn't required, the
standard still allows blanks before and after list items.
Note, though, that some languages allow one to specify how
output is produced. AWK has the OFMT and CONVFMT variables which
specify the format use for print statements, and for conversion
of numeric values to character string values. (The format values
could include one or more blanks.)
If one wanted to do something different from the current form,
one should allow a general specification of output values,
including blanks before and after list items, and any
non-blank separator.
robin....@gmail.com
Aug 19, 2019, 6:40:06 AM8/19/19
to
On Monday, August 19, 2019 at 5:15:21 PM UTC+10, ga...@u.washington.edu wrote:
> On Sunday, August 18, 2019 at 9:36:50 AM UTC-7, Gary Scott wrote:
>
> (snip)
>
> > I guess I could get used to it if ":" implied a well defined set of
> > formatting expectations rather than just suppressing the leading control
> > character.
>
> From the description in the standard of list-directed output:
>
> "The form of the values produced is the same as that required for
> input, except as noted otherwise. With the exception of adjacent
> undelimited character sequences, the values are separated by one
> or more blanks or by a comma, or a semicolon if the decimal edit
> mode is COMMA, optionally preceded by one or more blanks and
> optionally followed by one or more blanks."
>
> Note that besides the initial blank, believed to be for carriage
> control reasons, data items may be preceded or followed by blanks.
Blanks ARE produced to separate values (exception see below).
> On Sunday, August 18, 2019 at 9:36:50 AM UTC-7, Gary Scott wrote:
>
> (snip)
>
> > I guess I could get used to it if ":" implied a well defined set of
> > formatting expectations rather than just suppressing the leading control
> > character.
>
> From the description in the standard of list-directed output:
>
> "The form of the values produced is the same as that required for
> input, except as noted otherwise. With the exception of adjacent
> undelimited character sequences, the values are separated by one
> or more blanks or by a comma, or a semicolon if the decimal edit
> mode is COMMA, optionally preceded by one or more blanks and
> optionally followed by one or more blanks."
>
> Note that besides the initial blank, believed to be for carriage
> control reasons, data items may be preceded or followed by blanks.
They do NOT precede values. And one or more blanks can be used.
Note that the inserted character (blank, but see below)
SEPARATES values. That means, that the initial value is not
preceded by a blank, and that the final value is NOT followed
by a blank.
The exceptions are that the separation character can be a comma
or a semicolon (when decimal edit mode is COMMA). In this case,
blanks are not inserted.
> Even if the blank that started this thread isn't required, the
> standard still allows blanks before and after list items.
<snip>
Gary Scott
Aug 19, 2019, 8:37:47 AM8/19/19
to
directed formatting doesnt bother me much except rarely the leading
blank is annoying...but i'm used to it.
spectrum
Aug 29, 2019, 8:46:51 AM8/29/19
to
On Sunday, August 18, 2019 at 9:08:27 AM UTC+9, urba...@comcast.net wrote:
> Great that "g0" meets your needs, but for completeness note a caveat -- complex values are rendered very differently when using g0 than when using list-directed output (...snip...)
Thanks very much for this point. I've just tried the code, and indeed '(*(g0:, " "))'
omits the output of parentheses for complex numbers. So I think we need to be careful
when using complex variables... (fortunately, I guess I will need only real
variables for the time being, though).
---
RE list-directed print without the first blank, introducing "println" might be
another approach (such that println works almost the same as print except for
the omission of the first blank).
print *, "hi", 100 !! this shows a first blank
println "hi", 100 !! this shows no first blank (otherwise the same output)
> Great that "g0" meets your needs, but for completeness note a caveat -- complex values are rendered very differently when using g0 than when using list-directed output (...snip...)
Thanks very much for this point. I've just tried the code, and indeed '(*(g0:, " "))'
omits the output of parentheses for complex numbers. So I think we need to be careful
when using complex variables... (fortunately, I guess I will need only real
variables for the time being, though).
---
RE list-directed print without the first blank, introducing "println" might be
another approach (such that println works almost the same as print except for
the omission of the first blank).
print *, "hi", 100 !! this shows a first blank
println "hi", 100 !! this shows no first blank (otherwise the same output)
Ron Shepard
Aug 30, 2019, 11:37:19 AM8/30/19
to
On 8/29/19 7:46 AM, spectrum wrote:
> RE list-directed print without the first blank, introducing "println" might be
> another approach (such that println works almost the same as print except for
> the omission of the first blank).
>
> print *, "hi", 100 !! this shows a first blank
> println "hi", 100 !! this shows no first blank (otherwise the same output)
The usual argument against changing this behavior is that if the
> RE list-directed print without the first blank, introducing "println" might be
> another approach (such that println works almost the same as print except for
> the omission of the first blank).
>
> print *, "hi", 100 !! this shows a first blank
> println "hi", 100 !! this shows no first blank (otherwise the same output)
programmer writes with list-directed i/o, then he has already said that
he doesn't care about the details of the output. If he is interested in
those details, then he should be using an explicit format.
However, if this leading space behavior is allowed to be changed, then I
think it should be through some combination of inquire() and open()
options, similar to changing decimal points and separators. That way, no
new syntax is required, no new parsing is required, the change is
localized to one place in the code rather than spread throughout, and so on.
There is one new capability that I have advocated in the past. In my own
programming, I often write output with an explicit format that I later
might want to read with list-directed i/o. Especially with the new i0,
f0, and g0 output formats, this is easy to do. However, one clumsy
feature of the current language that sticks out is that one cannot
specify a format that triggers list-directed i/o. Instead one must do
something like
if (ldioflag) then
read(unit,*) <list of items>
else
read(unit,fmt) <list of items>
endif
And of course, that if-else-endif structure must be repeated throughout
the code for every single read statement. It would be much easier and
less error prone to do something like
fmt = '(*)' ! this is only needed once.
...
read(unit,fmt) <list of items>
...
read(unit,fmt) <list of items>
...
read(unit,fmt) <list of items>
and so on.
$.02 -Ron Shepard
Message has been deleted
nshaffer
Aug 30, 2019, 5:52:36 PM8/30/19
to
On Friday, August 30, 2019 at 9:37:19 AM UTC-6, Ron Shepard wrote:
> ...
> ...
>
> There is one new capability that I have advocated in the past. In my own
> programming, I often write output with an explicit format that I later
> might want to read with list-directed i/o. Especially with the new i0,
> f0, and g0 output formats, this is easy to do. However, one clumsy
> feature of the current language that sticks out is that one cannot
> specify a format that triggers list-directed i/o. Instead one must do
> something like
>
> if (ldioflag) then
> read(unit,*) <list of items>
> else
> read(unit,fmt) <list of items>
> endif
>
> And of course, that if-else-endif structure must be repeated throughout
> the code for every single read statement. It would be much easier and
> less error prone to do something like
>
> fmt = '(*)' ! this is only needed once.
> ...
> read(unit,fmt) <list of items>
> ...
> read(unit,fmt) <list of items>
> ...
> read(unit,fmt) <list of items>
>
> and so on.
>
> $.02 -Ron Shepard
Hear, hear. My own encounter with this annoyance is writing utility functions that wrap internal write statements. I could envision a modest but useful enhancement to the language being a character constant (maybe defined in ISO_FORTRAN_ENV), which formats "as if list-directed".
> There is one new capability that I have advocated in the past. In my own
> programming, I often write output with an explicit format that I later
> might want to read with list-directed i/o. Especially with the new i0,
> f0, and g0 output formats, this is easy to do. However, one clumsy
> feature of the current language that sticks out is that one cannot
> specify a format that triggers list-directed i/o. Instead one must do
> something like
>
> if (ldioflag) then
> read(unit,*) <list of items>
> else
> read(unit,fmt) <list of items>
> endif
>
> And of course, that if-else-endif structure must be repeated throughout
> the code for every single read statement. It would be much easier and
> less error prone to do something like
>
> fmt = '(*)' ! this is only needed once.
> ...
> read(unit,fmt) <list of items>
> ...
> read(unit,fmt) <list of items>
> ...
> read(unit,fmt) <list of items>
>
> and so on.
>
> $.02 -Ron Shepard
robin....@gmail.com
Aug 30, 2019, 7:10:14 PM8/30/19
to
On Saturday, August 31, 2019 at 1:37:19 AM UTC+10, Ron Shepard wrote:
> On 8/29/19 7:46 AM, spectrum wrote:
> > RE list-directed print without the first blank, introducing "println" might be
> > another approach (such that println works almost the same as print except for
> > the omission of the first blank).
> >
> > print *, "hi", 100 !! this shows a first blank
> > println "hi", 100 !! this shows no first blank (otherwise the same output)
>
> The usual argument against changing this behavior is that if the
> programmer writes with list-directed i/o, then he has already said that
> he doesn't care about the details of the output. If he is interested in
> those details, then he should be using an explicit format.
Agreed.
> On 8/29/19 7:46 AM, spectrum wrote:
> > RE list-directed print without the first blank, introducing "println" might be
> > another approach (such that println works almost the same as print except for
> > the omission of the first blank).
> >
> > print *, "hi", 100 !! this shows a first blank
> > println "hi", 100 !! this shows no first blank (otherwise the same output)
>
> The usual argument against changing this behavior is that if the
> programmer writes with list-directed i/o, then he has already said that
> he doesn't care about the details of the output. If he is interested in
> those details, then he should be using an explicit format.
But why is there still discussion about it?
Shakespeare had a word for it:
"Much ado about nothing."
0 new messages