Commas in FORMAT statements. Whats the standard?
John H. Chauvin
edit descriptor immediately preceding a numeric edit descriptor
unless it is separated by a comma. That is:
3P8E10.3 <==== flagged as an error
whereas 3P,8E10.3 <==== No error
Is the first usage an extension to F77?
What exactly does the F77 standard say about the use of commas in
FORMAT statements? Is this going to change with F90?
Thanks
John Chauvin
--
John H. Chauvin jcha...@netcom.COM
Netcom - Online Communication Services San Jose, CA
Steve Lionel
In article <jchauvin...@netcom.com>, jcha...@netcom.com
(John H. Chauvin) writes...
>I have noticed that some compiler will not let you list a scale factor
>edit descriptor immediately preceding a numeric edit descriptor
>unless it is separated by a comma. That is:
>
> 3P8E10.3 <==== flagged as an error
>
>whereas 3P,8E10.3 <==== No error
>
>Is the first usage an extension to F77?
>What exactly does the F77 standard say about the use of commas in
>FORMAT statements? Is this going to change with F90?
>
Ah, you've discovered the standards question which has caused me a fair
amount of hair pulling. The VAX FORTRAN (now DEC Fortran for OpenVMS
VAX) compiler allows either syntax, and, as of V5.0, did not diagnose
the omission of the comma as a standards extension. After receiving
a complaint from a user who maintained that it WAS an extension.
My reading of the standard agreed, and I modified the compiler's flagger
to diagnose this.
Then, of course, I got a new complaint that we DID flag this as
an extension! Here's my reply to that report:
===
Thank you for your inquiry. We made the change to the VAX FORTRAN compiler for
version V5.1 to add the case of a missing comma between a scale factor and
a repeated edit descriptor to the list of syntactic extensions to the
ANSI standard that are diagnosed by the compiler. This change was deliberate
and was made after careful study of the text of the standard.
The relevant text is on page 13-2 of the standard. Lines 26-30 say:
The comma used to separate list items in the list _flist_ may
be omitted as follows:
(1) Between a P edit descriptor and an immediately
following F, E, D or G edit descriptor (13.5.9).
At first glance, this might seem to allow the comma to be omitted in a
format of 1P10E12.3, but closer examination shows otherwise.
The key is the phrase "F, E, D or G edit descriptor". And the question is:
"Is 10E12.3 an 'edit descriptor' in this context?" We believe it is not.
Section 13.2.1, also on page 13-2, defines "Edit Descriptor", and says that
it "is either a repeatable edit descriptor or a nonrepeatable edit descriptor".
Looking at the forms of edit descriptors, one finds that the form rEw.d is
not present. Indeed, the repeated form is described above in lines 7-23
as an _flist_ item, consisting of a _repeat specification_ followed by a
repeatable edit descriptor. Since lines 29-30 did not say that the comma
could be omitted between a P edit descriptor and an _flist_ item, we
concluded that such omission would be treated as an extension.
However, the situation is not completely clear. First, we discovered that
the FCVS test FM110 contains a format item of this form. And second, you
pointed out that the syntax diagram in Appendix F of the standard appears
to allow the comma to be omitted.
We note that the introduction to Appendix F indicates that if there is a
conflict between it and the text of the standard, that the text prevails, but
there is sufficient doubt in our minds such that we intend to ask the standards
committee if indeed it was the intent of the text to allow omission of the
comma in this case. If we receive an interpretation that indicates the comma
may be omitted in this case, we will remove this check from future versions
of our compilers.
===
After learning from our standards rep that nobody was doing new interpretations
of F77, I wrote to NIST, which maintains the FCVS validation suite, and
asked for an opinion about FM110. The response I got said that they
considered omission of the comma to be standard-conforming, but the
explanation I was given made no sense to me. Still, this was as close to
an "official word" as I was going to get, so I backed out the check in
a later version.
F90 contains the same wording as F77, so that's no help. (F90 doesn't
have the railroad-tracks syntax chart either.) What say you
language lawyers?
Steve Lionel lio...@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062 "Free advice is worth every cent"
Len Moss
Lionel) says:
> [discussion of whether 3P8E10.3 permitted in F77 format]
>F90 contains the same wording as F77, so that's no help. (F90 doesn't
>have the railroad-tracks syntax chart either.) What say you
>language lawyers?
>
X3J3 has addressed this issue, both for F90 and F77, and has
submitted the following [NB] _draft_ interpretation to SC22/WG5:
NUMBER: 000050
TITLE: Repeat counts on edit descriptors
KEYWORDS: edit descriptor, repeat count
DEFECT TYPE: Interpretation
STATUS: WG5 approved; ready for SC22
QUESTION: Is the repeat specification part of the edit descriptor?
In section 10.1.1 the second constraint states that the comma separating the
<format-items> in a <format-item-list> is optional between certain combinations
of edit descriptors.
In section 10.2 a format-item is defined as, amongst other things,
"[r]<data-edit-desc>" and in 10.2.1 an edit-descriptor can be a data-edit-desc.
However, <data-edit-desc> does not contain the repeat count. This implies that:
100 FORMAT(1PE20.10) ! is legal
200 FORMAT(1P3E20.10) ! is not legal
300 FORMAT(1P,3E20.10) ! is legal
ANSWER: The repeat count is not part of any edit descriptor except the
"[r]/" edit descriptor.
The comments in the examples are correct.
REFERENCES: ISO/IEC 1539:1991, sections 10.1.1, 10.2, & 10.2.1
EDITS: None.
SUBMITTED BY: A.D. Tait, X3J3/92-041 (121-ADT-1)
HISTORY: X3J3/92-041
X3J3/92-042
This problem appears to stem from an incompatibility between FORTRAN 66
and FORTRAN 77. In FORTRAN 66 a FORMAT statement is of the form:
FORMAT(list)
where the list consists of a series of field descriptors separated by field
separators and optionally preceded and succeeded by slashes. The field
descriptors for real or double precision values consisted of the now familiar
Dw.d, Ew.d, Fw.d, and Gw.d edit descriptors (a term introduced in FORTRAN 77)
preceded by an optional scale factor and repeat count. For example, in FORTRAN
66 a valid field descriptor is 1P3E17.10, where 1P is the scale factor, 3 the
repeat count for a field containing 10 digits in the fractional part of the
number and having a E exponent.
In FORTRAN 77 the scale factor is an edit descriptor and thus is a list element
in the format specification. While FORTRAN 77 specifies places where the commas
separating list elements in a format specification are optional, it fails to
make a comma between the scale factor and an immediately succeeding repeated D,
E, F, or G edit descriptor optional. This situation has been carried over to
Fortran 90. Thus:
100 FORMAT(1PE20.10) ! is legal in F66, F77, and F90
200 FORMAT(1P3E20.10) ! is legal in F66, and illegal in F77 & F90
300 FORMAT(1P,3E20.10) ! is illegal in F66, and legal in F77 & F90
Edit approved in 92-267r at meeting 123.
N881 WG5 approval
--------------------------------------------------------------------------------
BTW, since F77 remains an American National Standard, it is
perfectly in order to request an interpretation of this standard
from X3J3. If the question is at all relevant to F90, the request
will be considered in the context of both languages in order to
preserve their compatibility. However, the procedures are
complicated by the fact that SC22/WG5 is the final authority on F90
but has nothing to do with F77 (which is no longer an international
standard). The above draft is an attempt to deal with this problem
(at least in some cases) by providing an authoritative F90 response
to the question (in the section labelled 'ANSWER', above), along
with an historical note explaining the corresponding situation
in F77 (and in this case, F66 as well).
--
Leonard J. Moss <l...@slac.stanford.edu> | My views don't necessarily
Stanford Linear Accelerator Center, MS 97 | reflect those of SLAC,
P.O. Box 4349; Stanford, CA 94309 | Stanford or the DOE
Steve Lionel
In article <93263.1...@SLACVM.SLAC.STANFORD.EDU>,
|>
|> 100 FORMAT(1PE20.10) ! is legal in F66, F77, and F90
|> 200 FORMAT(1P3E20.10) ! is legal in F66, and illegal in F77 & F90
|> 300 FORMAT(1P,3E20.10) ! is illegal in F66, and legal in F77 & F90
|>
|>Edit approved in 92-267r at meeting 123.
|> N881 WG5 approval
|>
Thanks! Now I get to go back and put this back in the flagger! This is
a good enough answer for me - though it does make FCVS78 test FM110
"illegal"! (Which brings to mind that the original posting described a
compiler which would not accept omission of the comma; this suggests that
that compiler could not possibly have been validated against X3.9-1978.)
--
IanMaclure
>I have noticed that some compiler will not let you list a scale factor
>edit descriptor immediately preceding a numeric edit descriptor
< Text Deleted >
Irrespective of whether it is a requirement or not, IMHO it never
hurts to use a comma, parenthesis, etc.
This enhances readability and makes it explicitly, even painfully
clear exactly what the author meant.
Also, you don't get these sorts of questions with accompanying
head scratching, etc.
IBM
--
################ No Times Like The Maritimes, Eh! ######################
# IBM aka # ian_m...@QMGATE.arc.nasa.gov (desk) #
# Ian B MacLure # maclure@(remulac/eos).arc.nasa.gov (currently) #
########## Opinions expressed here are mine, mine, mine. ###############
Bill Leonard
>
> Thanks! Now I get to go back and put this back in the flagger! This is
> a good enough answer for me - though it does make FCVS78 test FM110
> "illegal"! (Which brings to mind that the original posting described a
> compiler which would not accept omission of the comma; this suggests that
> that compiler could not possibly have been validated against X3.9-1978.)
Actually, it could and probably was. A little-known fact about Fortran
validations is that you can be validated with a certain number (I think 3)
of failures! These failures are noted in the validation report that NIST
issues. The next time you try to validate, you must have corrected any
failures from the previous validation, but you can have new ones!
I should probably say that this is only my understanding of the situation
as of several years ago; NIST may have changed the rules since then.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bi...@ssd.csd.harris.com
These opinions and statements are my own and do not reflect the opinions or
positions of Harris Corporation.
------------------------------------------------------------------------------
Let's put an end to infinity.
------------------------------------------------------------------------------
Ron Shepard
>jcha...@netcom.com (John H. Chauvin) writes:
>>I have noticed that some compiler will not let you list a scale factor
>>edit descriptor immediately preceding a numeric edit descriptor
>
> < Text Deleted >
>
>Irrespective of whether it is a requirement or not, IMHO it never
>hurts to use a comma, parenthesis, etc.
>This enhances readability and makes it explicitly, even painfully
>clear exactly what the author meant.
>Also, you don't get these sorts of questions with accompanying
>head scratching, etc.
This is a minor nit to pick, but a format such as
(..., 1p6e12.4, ..., e12.4, ... )
LOOKS as if the 1p scale factor applies only to the 6e12.4 fields, while
in fact it applies to the rest of the format unless overridden
explicitly. The format
(..., 1p,6e12.4, ..., e12.4, ... )
makes it appear more like the 1p is something that stands by itself, and
applies to all of the remaining fields (as it does).
As far as compiler warnings go, I must admit that I did not know before
this thread that the comma was REQUIRED in f77.
$.02 -Ron Shepard