To: J3                                                     J3/25-105
From: Malcolm Cohen
Subject: Editor's report for 25-007 production
Date: 2025-January-27


1. Introduction

This document reports additional changes made to 007 during the application
of 24-182r1 to 24-007. This does not list the specific edits from 24-182r1
that were applied without change.


2. A note

LaTeX is not all that great at justifying paragraphs, if it has any problem
it chooses the worst of all possible worlds, viz the text sticks out into
the right margin. Yes, this is even less acceptable than great gobs of
white space within a line.

This deficiency is even worse when working with eleven-point text.
Additional wordsmithing may be warranted at a later date to improve things.
But for now, I got rid of all the "sticking into the margin" cases; details
below for most of them, especially the difficult ones. I made a number of
editorial changes to the text in this process: all of those are noted.


3. Obsolescence marking

As I did this, I changed my view, to some extent, as to how/whether the
obsolescent things should be marked. My final position is that the most
important thing is to specify in normative text in the definition of the
obsolescent feature itself, that it is obsolescent. In other places in the
document, it is frequently just distracting to be reminded that common
blocks (or whatever) are obsolescent. So I would probably support deleting
a lot of the footnotes that I put in, especially earlier in the document.

Oh, and although it's nice to have "(obsolescent)" clearly in the heading
of a subclause that defines an obsolescent feature, headings are not in
themselves normative text. There needs to be normative text. I believe I
inserted all the normative text needed for this.


4. Extra edits

[internal] Add "j3fancyhdr.sty", which is a copy of an obsolete version of
the common "fancyhdr.sty" package. The latest version of fancyhdr uses
"parbox" to format the headers and footers, which interacts badly with our
paragraph numbering system, viz it puts paragraph numbers into the headers
and footers. Thus, j3fancyhdr which does not.

NOTE: the Foreword has a list of major changes, so any big features
      should add a very brief description to the list in the Foreword, as
      well as in the Introduction (the version in the Introduction can be
      more detailed, if warranted).

EXTRA [xiii] Introduction, p1 and p2,
             Change "2023" to "2028" many times,
             Then change all the "2018" to "2023".

EXTRA [xiii] Deleted the bullet point
    "Changes to the intrinsic module IEEE_ARITHMETIC for conformance with
     ISO/IEC 60559:2020"
instead of leaving it as an empty heading.

NOTE [33:19+] Insert new subclause "4.3.3 Fortran 2023 compatibility"...
    I omitted "Except as identified in this subclause," because we do not
    have any incompatibilities yet. When we do, that will need to be
    changed. Similarly, omitted "that does not use any feature identified
    in this subclause as being no longer permitted".

EXTRA [37:37] 4.4.1 General (in 4.4 Deleted and obsolescent features), p1,
              "six" -> "eight"
{We now have deleted eight features of Fortran 90!}

DIFFERENT
[37:39-40]  "redundant in Fortran 77 and largely unused in Fortran 90"
            ->"redundant in Fortran 90 and largely unused".
{Non-block DO was the only DO in Fortran 77, so not redundant in 77.
 Besides which, overly specific.}
[37:41] "90 and Fortran 95" -> "2008".
{DO CONCURRENT was added in F2008, so FORALL was not redundant until then.}

EXTRA [37:44] 4.4.2 Nature of deleted features, p1,
    "Fortran 95, Fortran 2003, or Fortran 2008,"
    ->"Fortran 95 and later revisions,"
{Omit list that was already missing some of the revisions!}
[37:46] Changed
    "were included in Fortran 2008, but are not included in this document"
changed to
    "were not included in Fortran 2018 and later revisions, and are not
     included in this document".
{Update text unchanged since F2018 to be more accurate; there is only one
 "later revision", but this wording will work in future revisions too.}

EXTRA [38:2] 4.4.3 Nature of obsolescent features, p1,
             "Fortran 90 and Fortran 95" -> "a previous Fortran standard".
{Unnecessarily overly specific. Also, it was wrong.}

EXTRA [38:5] same subclause, p3, replace whole paragraph
    "A future revision of this document might delete an obsolescent feature
     if its use has become insignificant."
with
    "An obsolescent feature is eligible for deletion from a future revision
     of this document if its use has become insignificant."
{Passive voice works better here, and avoids using an auxiliary verb that
 might annoy an ISO editor.}

DIFFERENT
[563:15] B.3.1 General [in B.3 Obsolescent features], p1,
  Wrong location and wrong context (the first "90" is after "of Fortran 90"
  not "in..."). Also, the rewrite omits the crucial distinction that the
  obsolescent features have better available methods in an older standard.
Changed to
    "The obsolescent features are those features of Fortran that were
     redundant in a previous standard, and for which better methods were
     available in that standard."

DIFFERENT
 [566:4-] Insert "C.1 Feature list
    -> "Feature history".

EXTRA [Clause 3]
    In the term "common block", Note 1 to entry,
    changed "COMMON blocks" -> "Common blocks".

NOTE
    Did not note block data being obsolescent in the "main program" term
    definition; maybe that definition should be rewritten as what it IS
    instead of what it is NOT.

NOTE Clause 5
    I deliberately did not footnote (or note in any way) some of the
    obsolescent features, e.g.
        R502 program-unit ... or block-data
    and many others in the high-level syntax summary, as this is not
    significant enough and would disrupt the presentation; it is sufficient
    to note it when discussing the features themselves.

    Similarly 5.2.1p1 block data in the list of program units
    (I did mention it in p2, in normative text not as a note.

    5.3.3 The END statement
    {because the obsolescence is being ruled out, and is insignificant}

Clause 7

NOTE Did not add anything to C707 as although it pertains only to
     obsolescent syntax, it would be distracting..

COMMENT: In 7.3.2.1 Type specifier syntax, NOTE 1,
    "An \si{integer-type-spec} is used in a \refstmtx{DO CONCURRENT}
     \obs{or \refstmtx{FORALL}} statement."
it could say
    "...in a \si{concurrent-header}."
instead, avoiding mention of the obsolescent thingo. Is that a good idea?
In any case, I did not add any text about FORALL being obsolescent here as
it does not seem that important.
COMMENT: Also, I think all the \si here should be \su
         by which I mean unindexed references.

After R722, inserted paragraph stating that the relevant syntax is
obsolescent.

EXTRA: C726, final bullet, inserted "subprogram" after "external function"
       for correctness (the syntax is subprogram, a function is what the
       creates).

COMMENT: Why is C726 limited to only applying to type-param-value in a
         char-selector, length-selector, or char-length?
         I think this is just wrong... the penultimate bullet assumes it
         applies to derived-type-spec... more research needed.
{That is for /DATA subgroup.}

Although I added a parenthetical "this usage is obsolescent" to the final
bullet of C726, I think this would be better stated about half a page later
when we describe the semantics of assumed character length functions.

COMMENT: Delete the parenthetical remark in C726???

NOTE: In C727, the whole phrase
         "and is the name of a dummy function or the name of the result of
          an external function"
      is redundant as that is a direct consequence of C726.

COMMENT: Could merge C727 and C728, as C728 is just applying a bunch of
         extra conditions to the situation in C727?
         Probably not worth bothering with...

COMMENT: Why is C728 entirely in obsolescent font? Surely it applies to the
         non-obsolescent assumed-length dummy function situation?

The note of obsolescent I added to C726 (or indeed, the normative text
lower down) covers any obsolescence in C728 already, so nothing more needs
to be noted in C727-C730 in my opinion.

COMMENT: C729 and C730 should have the "(R722)" removed, and should be
         merged into a single constraint.

C731 is about statement functions, so that gets a footnote.

7.4.4.2, final bullet, reformatted to make all the text obsolescent font
(except for the new text stating obsolescence), and inserted witter saying
that this is an "assumed character length function".

In 8.5.5 Bind attribute for data entities, specify that common blocks are
obsolescent in normative text at the end of p1, then appended p3 to p1.

Added new subclauses specifying obsolescence normatively for storage
association and forall. Yes, storage association is obsolescent (there is
no way of reaching without using another obsolescent feature) but we never
bothered to say it before. Well, we do now.

EXTRA: It has come to my attention that there is a Fortran 2008 feature not
mentioned in the Introduction, viz i/o of real/complex internal
representation using B, O, Z. Added to Features History.

NEEDS TO BE FIXED:
Also, bug in the description (in B, O, and Z editing): p5 says
    "without leading zero bits",
but O and Z cannot in general do that!
(There being no way to write the decimal value 2 in Z format without
two leading zero bits.)
It should say "without leading zeros".

C1505 could be rewritten to avoid mentioning the obsolescent feature by
      using "named dummy arguments", as alternate return indicators are
      not named. Maybe too subtle, so I didn't do it.

DIFFERENT [38:4] 4.4.3 Nature of obsolescent features, p2,
       change "by a distinguishing type font (4.1.5)"
       to "by footnotes or headings".
Instead, just deleted it. As they are all now (I hope!) specified to be
obsolescent in normative text we do not need a "convention".

ASIDE Defined a lot of LaTeX stuff to do the font changes without massive
      changes to the document text, mostly by adjusting our environments.

EXTRA: ISO directives state:
            Tables shall be designated "Table" and numbered.
       We had a "nocount" LaTeX environment for tables that violated that
       requirement. It is only by mere luck that the ISO CS editor did not
       notice we had non-table tables.
THEREFORE turned the "bit result tables" for IAND et al into proper tables.

Lots of tables needed fixing, as they had hard-coded "[-10pt]" etc, which
is wrong with the new fonts and sizes. Unfortunately, I could not see
immediately a better way to do those spacing adjustments, so we have a new
bunch of hard coded magic numbers that will need changing if we change font
sizes again.

Table 9.1 had a gap in the box around it: fixed.

The NOTE after table 10.2 should be within the table.

NOTE: xelatex broke the display of our nihongo example, so I changed the
      LaTeX source file to UTF-8 and used a Japanese font. ISO might
      complain about us not using Cambria there, but there is no choice as
      Cambria does not have Japanese glyphs.

From here on, most of the changes were to address overlong lines or
overlapping text in BNF rules.

NOTE: With 11-point font, there is no spacing that works well for all BNF
      rules, as some rules have long names, and some have long productions
      that would look bad if crammed into multiple continuations. So, added
      new macros \wbnfn and \wbnfb (and others) for "wide" BNF names. This
      means that the position of the "is" and "or" will not always be the
      same column, but that is better than chopping the names short or
      squashing all productions into a narrow space.

Deleted the unnecessary "(R741)" in C760 to avoid overlong line.
In C766, deleted "(R737)" and inserted "in a data-component-def-stmt",
to avoid very long line.
In C766, deleted unnecessary "(R751)" to avoid overlong line.

In 7.6.1 Interoperable enumerations and enumtypes, p6, there was an
enumerated list where there was no meaning to the ordinals (no ordering
between items, and no reference from elsewhere); changed to a bullet list
to reduce line length.

Inserted an unnecessary but harmless "type" in C824 to convince TeX to
break the line.

Moved stuff around in R844 to avoid another long line.

Deleted unnecessary "(R849)" in C888 (it already says data-stmt-constant),
to avoid an overly-long line.

C897 used raggedright It could be reworded,
perhaps "has ...-list" -> "specifies TYPE or does not specify EXTERNAL".

C941 inserted unnecessary but harmless "type" to adjust TeX line-breaking.

Singularised second sentence of 10.1.2.4 Level-1 expressions, p1, to avoid
an overlong line.

10.1.6.1 Definitions, p4, "that has the form" -> "with the form", to avoid
an overlong line. The is a slight wording inconsistency with p1 now, may be
worth wordsmithing p1 and/or p4 further.

10.1.11 Specification expression, p3,
item (3), "from the intrinsic modules IEEE_ARITHMETIC and IEEE_EXCEPTIONS"
-> "from the intrinsic module IEEE_ARITHMETIC or the intrinsic module
IEEE_EXCEPTIONS" to give TeX somewhere it can break the line.

10.1.11 Specification expression, p3,
enabled raggedright to avoid overlong line.

10.2.1.3 Interpretation of intrinsic assignments, p12,
enabled raggedright to avoid overlong line.

C1017, enabled raggedright.
C1028 ditto

C1039 deleted unnecessary (R1053) to avoid overlong line.

10.2.4.3.2 Determination of the values for index variables, p1,
inserted hard line break before the cross-reference, as the line was too
long. Perhaps it could be reworded? (Shorter to make it fit, or longer to
make it breakable by LaTeX).

COMMENT: 10.2.4.3.4 Execution of the FORALL body constructs, p1,
paragraph ends with a colon. This is ungrammatical. Reword please.
(/DATA or /EDIT subgroup.)

10.2.4.3.4 Execution of the FORALL body constructs, p5,
penultimate line of para is overlong. Reword please.

R1125 and R1126 lines overlong, inserted continuations.

C1145 raggedright
C1160 ditto

11.2.1 Branch concepts, p1, manual line break.
- perhaps we could make a table of branch target statements instead of the
wall of text? Please? Pretty please?

11.7.8 EVENT WAIT statement, p3, hard line break inserted.
(Should we have an enum environment with a smaller indent?)

11.7.10 LOCK and UNLOCK statements, p1, silly (but okay?) hyphenation to
avoid overlong.

Clause 1, p4, antepenultimate bullet, hard line break inserted as
otherwise the ref to the IEEE arith std is an overlong line. Maybe this
could be reworded so that it appears elsewhere in the sentence? (We do not
want a hyphenated reference here.)

Clause 3, term "name association".
Hard line break inserted in the list.
Looking at it, we do not ever use the term "name association" except in the
name association subclause, so this does not need to be a defined term.
RECOMMEND deleting it or moving to a new Annex "Glossary of non-terms".

term "branch target statement".
Hard line break inserted.
STRONG RECOMMENDATION:
The requirement should be removed from here as it duplicates the list in
11.2.1, almost certainly guaranteeing that one or both of them will be
wrong in the future. Anyway, the list should be a table as that would be
more readable and pose fewer typesetting issues.

term "team number"
changed the "that" to a "which" for wording consistency,
changed "sibling teams (ref)" to "siblings"; this is the very next
term after "sibling teams", so the reference number is simply unnecessary.
Besides which, "siblings" works perfectly well, and as it's not a defined
term, should not invoke the wrath of the ISO editor who wants term usage in
clause 3 to be italicised with the stupid reference number.

6.2.1 Tokens, p1: raggedright had no effect, hard line break inserted.

COMMENT: Sometimes, raggedright is ignored by LaTeX. I'm sure there is a
         reason for that, but I could not discern any pattern.

7.4.4.2 Character type specifier, p5, raggedright ineffective, manually
hyphenated a syntax term (which is not a good idea, but...)
RECOMMEND Rewrite this wall of text to make it simpler, easier to
understand, and easier to typeset.

C897 raggedright worked.

11.7.8 EVENT WAIT statement, p3, raggedright (entire para as I don't seem
to be able to do it for just a single item).

11.7.10 LOCK and UNLOCK statements, p1, horrible manual hyphenation to
avoid overlong.

12.5.4 Connection of a file to a unit, p5,
Hard new line inserted.
RECOMMEND: Can we split up, simplify, rewrite etc. this wall of text?
Something that does not put the indigestible lump of the ISO C reference at
the end of a line?

12.5.6.4 ACTION= specifier in the OPEN statement,
COMMENT wall of text
Inserted hard new line.
Correct mismatched number "any ... statements" -> "any ... statement".

12.5.6.12 LEADING_ZERO= specifier in the OPEN statement
Permitted suboptimal hyphenation of LEADING_ZERO, to avoid long line.

C1225 raggedright worked.

12.6.2.7 DECIMAL= specifier in a data transfer statement, p1, raggedright
ineffective, did silly hyphenation of "changes" instead.
(Alternative would be a hard newline before "changes".)

C1309 hyphenate "descriptor".

13.7.2.3.6 EX editing, p5, insert "of the exponent" after "the form" to get
better line breaking.

13.7.2.3.7 Complex editing, allow "descriptor" hyphenation.

13.7.5.4 Generalized character editing, allow "nonzero" hyphenation.

13.8.5 LZS, LZP and LZ editing, p1, overlong: moved the cross-references
from the first sentence to immediately follow "LEADING_ZERO= specifier"
(which is literally what they are references to).

13.8.7 BN and BZ editing, p1, overlong: similarly.
Same subclause, p3: raggedright ineffective, inserted hard new line.
COMMENT: Could we reword this please? LaTeX can sometimes hyphenate words
(though it often needs a little help), but it can never hyphenate cross-
references. Maybe we do not even need the cross-references? We could move
them all the way to the end of the sentence i.e. after "on input", but that
seems a bit gratuitous as they are not input-specific.

13.8.9 DC and DP editing, p1, overlong: moved the cross-references to
follow the DECIMAL= specifier (which is what they are referring to).

C1401 overlong: removed syntax ref and reworded.

C1411 overlong: deleted unnecessary redundant syntax ref.

C1415 ditto.

15.2.2.2 External, internal, andmodule procedures, p3,
allow "provided" to be hyphenated. Yes that is horrible. But extending
into the right margin, even by 3 points, is unacceptable.

15.3.1 Characteristics of procedures, p1, allow "whether" to be hyphenated.

15.3.2.2 Characteristics of dummy data objects, p1, reworded by moving
"or a target (...)" into the attribute list (as "TARGET (...),").
Yes, the current wording notes that things cannot simultaneously have
POINTER and TARGET attributes, but they also cannot have ALLOCATABLE and
VALUE, etc., so in my opinion that is not important to mention here.

15.4.2.2 Explicit interface, p1, item 4(a) overlong, made entire subclause
raggedright.

C1543 overlong, inserted extraneous but harmless "also".

15.5.2.5 Ordinary dummy variables, p9, first bullet, hyphenated "dummy".

15.5.2.14 Restrictions on entities associated with dummy arguments,
item (1), added some verbiage to get LaTeX to wrap it better.

15.5.3 Function reference, p1, overlong, inserted "either" to give LaTeX
better line-breaking opportunities.

C1576, deleted syntax ref, reworded.

15.6.2.5 Separate module procedures, p1, allow function-subprogram to be
hyphenated.

16.1 Classes of intrinsic procedures, p5, raggedright ineffective, enabled
alternative hyphenation of TOKENIZE.

16.7 NOTE 1, ragged right ineffective, hard newline inserted.

16.9.68 CSHIFT (ARRAY, SHIFT [, DIM]), Examples, Case (ii), deleted "all".

STOPPED_IMAGES, TEAM argument, raggedright

18.3.7 Interoperability of procedures and procedure interfaces, p2, (6),
inserted hard new line. Could probably reword, but there is no obvious
rewording that is not clumsy?

18.5.1 Summary of contents, p1, raggedright ineffectual. Added hyphenation
instead, to "macro" and "non-interoperable";
EXTRA corrected "non-interoperable" to "noninteroperable".

18.5.5.7 The CFI_section function, p3 Description, first line, raggedright
did not work, so hyphenated "descriptor".

19.5.2.5 Events that cause the association status of pointers to become
undefined, p1, item (14)(b), inserted "the" before "source-expr".

Annex A,
"the case of characters assigned to the variable in a NAME= specifier in an
INQUIRE" raggedright ineffective, hard new line inserted.

"the value assigned to a CMDSTAT, ERRMSG, EXITSTAT,"
extra hyphenation for processor-dependent.

"which argument is the result value of IEEE_MAX_NUM, IEEE_MAX_NUM_MAG"
inserted "of the" between "both arguments".

In "the requirements on the storage sequence to be associated with the
    pointer FPTR by"
changed "to be" to "to become" (to avoid overlong).

C.13.3 Example of C calling Fortran (18.3), p6,
reworded first sentence to avoid overlong.

10.2.4.2.4 Execution of the FORALL body constructs, p5, overlong.
Changed "Any where-assignment-stmt" to "A where-assignment-stmt".

THIS_IMAGE examples were wrongly typeset, fixed.
However, the second example is both incomplete (no declarations) and it is
not very interesting.
RECOMMEND: Delete the second example or improve it?

===END===