J3/14-188
To: J3
From: Malcolm Cohen
Subject: Bad language (editorial changes)
Date: 2014 June 09


1. Introduction

This paper contains editorial changes for 14-007r1.  The only technical
effects intended are to make the standard specify requirements in normative
text that were previously ineffective due either to bad wording or to
stating it in informative text.

A number of other grammatical and typographical changes are also included,
where the editor noticed a glitch while looking at "may".


2. The incorrect language usage.

Multiple uses of "should" in informative text.  The ISO guidelines
explicitly prohibit this: informative text such as notes, examples and
informative annexes are not permitted to contain any requirement.  (The
latest guidelines specifically mention "should" in this context.)  I am
including uses of "recommend" in this category since it has the same
effect.

Multiple uses of "may" in informative text.  The ISO guidelines strictly
prohibit requirements in non-normative text!  That includes "giving
permission" to do something.

Multiple uses of "shall" in informative text.  Sometimes this is just
copying what the normative text says, but other times the requirement seems
to be only stated informatively.  This is an even more blatant violation of
the ISO guidelines.  Requirements that we intended to apply need to be in
normative text, ones that are just badly-stated pious hopes need to be
deleted, and ones that are mere restatements of normative text need to be
changed to statements of fact, capability, or possibility.

Unsurprisingly, sentences/paragraphs/notes with these failings also
frequently have other problems.  In such cases, the comment with the edit
has discussion about these.  In several cases, the editor's recommendation
is simply to delete the note as being uninformative or just plain wrong.


3. Edits (to 14-007r1)

[24:21+-22-] 1.5 Conformance, NOTE 1.11,
             Turn entire note into normative text (as two paragraphs).
{Editorial (g).}

[35:0-1-] 2.3.4 Program execution, NOTE 2.4,
  Replace penultimate sentence
    "Portable .. exact number of images."
  with
    "A program that makes assumptions about the exact number of images is
     unlikely to be portable."
{Editorial (g).}
  Delete ultimate sentence
    "The maximum number of images may be limited due to architectural
     constraints."
  as apart from being badly stated, this is covered by 1.1p4.
{Editorial (h).}

[35:37] 2.3.4 Program execution, p3,
        Append sentence
          "When error termination on an image has been initiated, the
           processor should initiate error termination on other images
           as quickly as possible."
{Editorial (g); this is the normative version of NOTE 2.8}

[35:37+] 2.3.4 Program execution, NOTE 2.6,
         Change into a new paragraph of normative text.
{Editorial (g).}

[36:0+6-9] 2.3.4, NOTE 2.8, Delete entire note
           "Within the performance limits ... stop execution.".
{Editorial (g); see 35:37 above for normative insertion.}

[39:2+0-3] 2.4.6 Array, p2 and NOTE 2.12,
  Turn entire note into normative text and append it to p2.
{Editorial (h).}

[41:16+5] 2.5.7 Companion processors, NOTE 2.17,
          "may allow" -> "might allow".
{Editorial (h).}

[45:0+3] 3.2.2 Names, NOTE 3.3,
         "may be" -> "can be".
{Editorial (h).  Yes, this is not actually giving permission.
 No, it is not helpful to use permissive words like this anyway.}

[46:18,18+10-11] 3.2.5 Statement labels, p2 and NOTE 3.4,
  Move the last two sentence from the NOTE,
    "There are ... one program unit."
  and append them to p2, changing
    "99999 unique" to "99999 possible unique".
{Editorial (h), plus clarify that we're just talking about possible labels
 not actual labels.}

[52:5+7] 4.2 Type parameters, NOTE 4.1,
         "may be" -> "can be".
{Editorial (h).}

[52:8+3] 4.2 Type parameters, NOTE 4.2,
         "may be" -> "can be".
{Editorial (h).}

[57:0+16] 4.4.2.3 Real type, NOTE 4.8, "should use" -> "can use".
{Editorial (g).}

[70:7+lots] 4.5.4.2 Array components, NOTE 4.29,
            "may be specified" -> "can be specified".
{Editorial (h).}

[71:3+14] 4.5.4.4 Pointer components, NOTE 4.31,
          "may" -> "could", twice.
{Editorial (h).}

[73:somewhere] 4.5.4.6 Default initialization for components, NOTE 4.34,
               "may be overridden" -> "can be overridden".
{Editorial (h).}

[73:elsewhere] 4.5.4.6 Default initialization for components, NOTE 4.35,
               "may be declared" -> "can be declared",
               "may also be initialized" -> "can also be initialized".
{Editorial (h).}

[73:otherwhere-74:0+4] 4.5.4.6 Default initialization..., NOTE 4.36,
                       "may have" -> "can have",
                       "may specify" -> "can specify",
                       "may be used" -> "can be used".
{Editorial (h).}

[74:0+8] 4.5.4.6 Default initialization for components, NOTE 4.37,
         "may be default initialized" -> "can be default initialized".
{Editorial (h).}

[79:21+3] 4.5.7.1 Concepts, NOTE 4.52,
          "type; it may appear only" -> "type; it can appear only".
{Editorial (h).}

[88:2+2] 4.8 Construction of array values, NOTE 4.69,
         "may be reshaped" -> "can be reshaped".
{Editorial (h).}

[101:0+lots] 5.3.10 INTENT attribute, NOTE 5.17,
  Change
    "If an argument should retain its value rather than being redefined,
     INTENT (INOUT) should be used rather than INTENT (OUT), even if there
     is no explicit reference to the value of the dummy argument."
  to
    "If an argument might not be redefined and it is desired to have the
     argument retain its value in that case, INTENT (OUT) cannot be used
     because it would cause the argument to become undefined; however,
     INTENT (INOUT) can be used, even if there is no explicit reference to
     the value of the dummy argument."
{Editorial (g).}

[104:10+12] 5.3.17 TARGET attribute, NOTE 5.24,
            "may point only" -> "can point only".
{Editorial (h).}

[105:16+1-4] 5.3.19 VOLATILE attribute, NOTE 5.25,
  Rewrite the note into normative text and a new note as follows:
    "The Fortran processor should use the most recent definition of a
     volatile object each time its value is required.  When a volatile
     object is defined by means of Fortran, it should make that definition
     available to the non-Fortran parts of the program as soon as
     possible.

     NOTE 5.25
     It is the programmer's responsibility to manage any interaction with
     the non-Fortran parts of the program."
{Editorial (g).  I am not entirely convinced that NOTE 5.25 is of any use
 or has any informative value whatsoever.}

[122:20+3] 6.4.5 Type parameter inquiry, NOTE 6.7,
           "may be used only" -> "can be used only".
{Editorial (h).}

[133:0+1-3] 6.7.3.2 Deallocation of allocatable variables, NOTE 6.23,
            Delete entire note, which says
  "The intrinsic function ALLOCATED may [sic] be used to determine whether
   a variable is allocated or unallocated.".
{Editorial (h).  This might have been microscopically noteworthy 23 years
 ago, but not any more.}

[140:0+16] 7.1.3 Precedence of operators, NOTE 7.9,
           "may be preceded" -> "can be preceded".
{Editorial (h).}

[140:0+lots] 7.1.3 Precedence of operators, NOTE 7.10,
             "may contain more" -> "can contain more".
{Editorial (h).}

[141:10+14] 7.1.4 Evaluation of operations, NOTE 7.12,
            "F or G may define X"
            ->"the reference to F and/or the reference to G can define X".
{Editorial (h).}

[141:16-16+3] 7.1.4 Evaluation of operations, p5 and NOTE 7.14,
              Turn entire note into normative text and append to p5.
{Editorial (h).  Alternatively, we could replace "may" with "could", since
 simultaneous execution is not detectable by a conforming program.}

[144:5+8] 7.1.5.2.4 Evaluation of numeric intrinsic operations, NOTE 7.19,
          "may be used" -> "can be used".
[144:5+lots] same NOTE 7.19,
             "shall not be used" -> "cannot be used".
{Editorial (h).  The alternative here would be to turn the whole note into
 normative text.}

[144:5+more,145:0+5] 7.1.5.2.4, NOTE 7.20,
                     "may be included" -> "can be included".
                     "parentheses may change"->"parentheses could change".
                     "may have different" -> "could have different".
{Editorial (h).}

[145:0+7,0+13] 7.1.5.2.4, NOTE 7.21,
               "may depend on" -> "can depend on",
               "may be either" -> "could be either".
{Editorial (h).}

[146:10+2] 7.1.5.4.2 Evaluation of logical intrinsic operations, NOTE 7.24,
           "may choose" -> "could choose".
{Editorial (h).}

[147:2+4] 7.1.5.5.1 Interpretation of relational intrinsic operations,
          NOTE 7.25,
          "may be compared" -> "can be compared".
{Editorial (h).}

[149:5+2] 7.1.6.1 Definitions, NOTE 7.27,
          "may be used" -> "can be used".
{Editorial (h).}

[153:9+2] 7.1.11 Specification expression, NOTE 7.32,
          "may be used" -> "can be used".
{Editorial (h).}

[158:10+4] 7.2.1.3 Interpretation of intrinsic assignments, NOTE 7.41,
           "copying may occur" -> "copying can occur".
{Editorial (h).}

[159:26+5] 7.2.1.5 Interpretation of defined assignment statements,
           NOTE 7.44,
           "may be performed" -> "can be performed".
{Editorial (h).}

[160:30+2] 7.2.2.2 Syntax of the pointer assignment statement, NOTE 7.45,
           "may be of a derived type" -> "can be of a derived type".
{Editorial (h).  I note that NOTE 7.45 is wildly misplaced, as it has less
 than nothing to do with the syntax of the pointer assignment statement.}

[176:27+2] 8.1.6.5.2 DO CONCURRENT loop control, NOTE 8.9,
           "variables may appear" -> "variables can appear".
{Editorial (h).}

[187:21+1-2] 8.2.3 Computed GO TO statement, NOTE 8.28,
             Delete entire note.
{Editorial (h), plus the note is not only about an obsolescent feature but
 is entirely uninteresting to boot.}

[189:21+lots] 8.5.2 Segments, NOTE 8.34,
              "an image may make a copy of a nonvolatile coarray"
              ->"the processor could make a copy of a nonvolatile coarray
                 on an image".
{Editorial (h), plus "an image" doesn't do this it is the processor.}

[193:0+lots] 8.5.5 SYNC MEMORY statement, NOTE 8.41,
             "should be" -> "is supposed to be".
{Editorial (g).}

[198:12+2-3] 9.2.4 Endfile record, NOTE 9.2,
             "may use a record count or other means"
             ->"can use a record count or any other means".
{Editorial (h), plus clarify we really are not attempting to specify the
 mechanism.}

[198:21+2] 9.3.1 Basic concepts, NOTE 9.4,
           Replace whole first sentence "For code ... should be used.":
  "If different files are needed on each image, using a different file name
   on each image will improve portability of the code."
{Editorial (g).}

[199:0+1-3] 9.3.2 File existence, NOTE 9.6,
            Delete entire note.
{Editorial (h) plus this note is completely uninteresting.  Alternatively
 we could change the first "may" to "could" and the second "may" to
 "might", but there seems to be little reason to keep the note anyway.}

[199:11+2] 9.3.3.1 File access methods, NOTE 9.7,
           "may allow only" -> "might provide only".
{Editorial (h).}

[200:0+2] 9.3.3.3 Direct access, NOTE 9.8,
          "may be rewritten" -> "can be written".
{Editorial (h).}

[201:0+2,3] 9.3.3.4 Stream access, NOTE 9.10,
            "may be some" -> "might be some",
            "may be written" -> "could be written".
{Editorial (h).}

[215:3] 9.6.2.5 ASYNCHRONOUS= specifier in a data transfer statement, p3,
        append new sentence
          "The documentation of the Fortran processor should describe when
           input/output will be performed asynchronously."
{Editorial (g); this text comes from C.6.6.}

[220:28+3-4] 9.6.4.1 General, NOTE 9.38,
             "may be reported" -> "can be reported",
             "may be impossible" -> "might be impossible".
{Editorial (h).}

[221:5+2] 9.6.4.3 Identifying a unit, NOTE 9.39,
          "may be preconnected" -> "could be preconnected".
{Editorial (h).}

[226:24+2] 9.6.4.8.3 Defined input/output procedures, NOTE 9.44,
           "may choose to interpret" -> "might choose to interpret".
{Editorial (h).}

[227:27+2] 9.6.4.8.3 Defined input/output procedures, NOTE 9.46,
           "A robust defined input/output procedure may wish to use"
           ->"A defined input/output procedure could use".
{Editorial (h) plus I see no reason to emphasise "robust" here - if we
 actually want to make a recommendation we can do so properly in
 normative text as "should use" ... but I think there are plenty of
 "robust" procedures that need not use INQUIRE to determine the settings.}

[230:25+2] 9.7.1 Wait operation, NOTE 9.50,
           "may be raised" -> "can be raised".
{Editorial (h).}

[233:24+3] 9.9 FLUSH statement, NOTE 9.57,
           "The intention is that the flush operation should"
           ->"It is expected that the flush operation will".
{Editorial (g).}

[236:28+2] 9.10.2.10 ENCODING= specifier in the INQUIRE statement,
           NOTE 9.60,
           "may be something" -> "could be something".
{Editorial (h).}

[237:11+5] NAME= specifier in the INQUIRE statement, NOTE 9.61,
           "processor may return" -> "processor could assign".
{Editorial (h), plus bad usage of "return".}

[242:24+2] 9.11.5 IOSTAT= specifier, NOTE 9.63,
           "condition may" -> "condition can", TWICE.
{Editorial (h).}

[246:0+8] 10.2.2 Character format specification, NOTE 10.3,
          "may be written" -> "can be written".
{Editorial (h).}

[248:32+2] 10.4 Interaction between input/output list and format,
           NOTE 10.4,
           "may be used only" -> "can be used only".
{Editorial (h).}

[249:24+lots] 10.4 Interaction between input/output list and format,
              NOTE 10.7,
              "may be used" -> "can be used".
{Editorial (h).}

[253:4+2] 10.7.2.3.2 F editing, NOTE 10.11,
          "may convey additional" -> "might convey additional".
{Editorial (h).}

[260:17+2,4] 10.8.2 Slash editing, NOTE 10.25,
             "may be written" -> "can be written",
             "may be skipped" -> "can be skipped".
{Editorial (h).}

[267:24+3] 10.11.3.2 Namelist input processing, NOTE 10.35,
           "may follow the equals" -> "can follow the equals".
{Editorial (h).}

[272:14+4-5] 11.2.1 General, NOTE 11.4,
             "shall not appear" -> "cannot appear",
             "they may appear" -> "they can appear".
{Editorial (h).}

[273:2+2] 11.2.2 The USE statement and use association, NOTE 11.7,
          "may be controlled" -> "can be controlled".
{Editorial (h).}

[275:6+3] 11.2.3 Submodules, NOTE 11.13,
          "may optionally have" -> "can have".
{Editorial (h).}

[280:6+4] 12.4.3.1 General, NOTE 12.2,
          "procedure may appear" -> "procedure can appear".
{Editorial (h).}

[281:40+2] 12.4.3.2 Interface block, NOTE 12.3,
           "may be different" -> "can be different".
{Editorial (h).}

[282:0+lots] 12.4.3.2 Interface block, NOTE 12.4,
             "procedures may use" -> "procedures can use".
{Editorial (h).}

[284:16+lots] 12.4.3.4.1 Generic identifiers, NOTE 12.9,
              "may be referenced" -> "can be referenced".
{Editorial (h).}

[292:0+7-8] NOTE 12.21,
            "the internal procedure may be invoked from outside of the host
             procedure scoping unit if that internal procedure was passed
             as an actual argument or is the target of a procedure pointer"
            ->"if an internal procedure was passed as an actual argument or
               is the target of a procedure pointer, it could be invoked
               from outside of the host procedure scoping unit".
{Editorial (h), plus reorder sentence to shorten and simplify grammar.}

[293:14+12] 12.5.2.1 Argument correspondence, NOTE 12.22,
            "may be invoked" -> "can be invoked".
{Editorial (h).}

[297:6+2] 12.5.2.5 Allocatable and pointer dummy variables, NOTE 12.30,
          "argument may change" -> "argument can change".
{Editorial (h).}

[299:0+6-7] 12.5.2.8 Coarray dummy variables, NOTE 12.33,
            "may use its own bounds" -> "can use its own bounds".
{Editorial (h).}

[300:20+2] 12.5.2.11 Sequence association, NOTE 12.35,
           "may consist of" -> "might consist of".
{Editorial (h).}

[303:0+lots] 12.5.2.13 Restrictions on entities associated with dummy
             arguments, NOTE 12.39,
             "X may be (indirectly)" -> "X can be (indirectly)",
             "Z may be directly" -> "Z can be directly",
             "X may, of course" -> "X can, of course".
{Editorial (h).}

[306:8+2] 12.5.5.3 Resolving procedure references to names established to
          be only specific, NOTE 12.43,
          "may be different" -> "can be different".
{Editorial (h).}

[309:11+5] 12.6.2.2 Function subprogram, NOTE 12.44,
           "may wish to defer" -> "might defer".
{Editorial (h), plus it seems unlikely that "an implementation" has any
 volition of its own.}

[310:0+3] 12.6.2.2 Function subprogram, NOTE 12.46 (cont.),
          "may be a C function" -> "could be a C function".
{Editorial (h).}

[315:11+5] 12.7 Pure procedures, NOTE 12.53,
           "may appear complicated" -> "appear to be complicated".
{Editorial (h).}

[317:16] 13.1 Classes of intrinsic procedures, p3 and NOTE 13.1,
  Move the first sentence out of the note, joining it to the last sentence
  of p3 as a run-on sentence, making the entire (new) sentence read
    "How sequences of atomic actions in unordered segments interleave with
     each other is processor dependent, and the order of accesses to atomic
     variables may appear to be inconsistent between different images or
     between different variables."
  In the previously-second-now-first sentence of the note, change
    "to use these" -> "to use atomic variables".
{Editorial (h); it is far from clear that the first sentence of the note is
 adequately covered by other (normative) text, so it is best to say it
 directly in normative text.  Also, the unbound "these" in the second
 sentence was inadequately anchored, so make it explicit what it is talking
 about.}

[320:19+2] 13.5 Standard generic intrinsic procedures, NOTE 13.6,
           "may be written" -> "can be written".
{Editorial (h).}

[321:0+7] 13.5 Standard generic intrinsic procedures, NOTE 13.7,
          "that may be applied" -> "to be applied".
{Editorial (h), plus remove unnecessary doubt.}

[379:1] 13.7.127 PACK, p6 Examples,
        "may be ``gathered''" -> "can be ``gathered''".
{Editorial (h).}

[399:8] 13.7.175 UNPACK, p6 Examples,
        "may be ``scattered''" -> "can be ``scattered''".
{Editorial (h).}

[400:6+1-3] 13.8.1 General, NOTE 13.29,
            Delete entire note.
{Editorial (g), plus the note is simply a programming (coding) guideline
 that is equally applicable to ALL module usage not just standard intrinsic
 modules (in fact one might opine that nonstandard intrinsic modules and
 user modules are far more likely to change to include additional items at
 the drop of a hat.  If we think we really do need to make this coding
 guideline explicit, it needs rewording, it needs to be in normative text,
 and it would be better placed in clause 11.}

[401:2] 13.8.2.6 COMPILER_OPTIONS, p5, append sentence
  "This value should include relevant information that could be useful for
   diagnosing problems at a later date."
{Editorial (g).}

[401:10] 13.8.2.7 COMPILER_VERSION, p5, append sentence
  "This value should include relevant information that could be useful for
   diagnosing problems at a later date."
{Editorial (g).}

[401:11+2-3,6] 13.8.2.7 COMPILER_VERSION, NOTE 13.30,
  Replace
    "For both ... For example,"
  with
    "Relevant information that could be useful for diagnosing problems at a
     later date might include"
  and delete
    "might be included".
{Editorial (g).}

[412:10+] 14.11.1 General, p2+, insert new paragraph
  "A program may contain statements that, if executed, would violate the
   requirements listed in a <<Restriction>> paragraph."
{Editorial (g).}

[412:10+1-413:0+8] 14.11.1 General, NOTE 14.9,
  Replace
    "It is intended ... containing code such as"
  with
    "A program can avoid violating this requirement by using IF constructs
     to check whether particular features are supported.  For example,"
  and replace
    "to avoid ... violated"
  with
    "avoids invoking IEEE_CLASS except on a processor which supports that
     facility."
{Editorial (g).}

[420:2+1-3] 14.11.20 IEEE SET HALTING MODE, NOTE 14.11,
            Delete entire note.
{Editorial (h); this note is simply a copy of earlier normative text - we
 do not need to say it twice.}

[421:0+1-2] 14.11.22 IEEE SET STATUS, NOTE 14.12,
            Delete entire note.

{Editorial (h); note is entirely uninteresting and untrue.  There are many
 things that "may [sic] be a very time consuming process".  This is not one
 of them!  Time-consuming yes, very no.}

[429:20+1-3] 15.2.1 Summary of contents, NOTE 15.1,
             Delete entire note.
{Editorial (g).  This is both unnecessary and redundant (it would be
 covered by the note in clause 13 if that were considered appropriate).}

[433:20+4-5] 15.2.3.6 C_LOC, NOTE 15.6,
  After "however,", replace
    "portable C functions should treat"
  with
    "only a C function that treats"
  and after
    "1999)"
  insert
    "is likely to be portable".
{Editorial (g).}

[435:4+10] 15.3.3 Interoperability with C pointer types, NOTE 15.11,
           "thus may be used" -> "thus can be used".
{Editorial (h).}

[436:11+4] 15.3.4 Interoperability of derived types and C struct types,
           NOTE 15.12,
           "may be the C address" -> "can be the C address".
{Editorial (h).}

[440:0+lots] 15.3.7 Interoperability of procedures and procedure
             interfaces, NOTE 15.22,
             "may correspond" -> "can correspond".
{Editorial (h).}

[440:0+more] 15.3.7 Interoperability of procedures and procedure
             interfaces, NOTE 15.23,
             "may be invoked" -> "can be invoked".
{Editorial (h).}

[444:0+1-4] 15.5.4 Macros and typedefs in ISO Fortran binding.h,
            NOTE 15.27,
            Delete entire note.
{Editorial (g) and (h), plus the note is completely uninteresting to the
 Fortran programmer, and the Fortran processor vendor either knows how to
 use version numbers in structures (in which case the note is completely
 unnecessary: requiring there to be a version number is sufficient) or does
 not know how to use them (in which case the note is too vague to be of
 use).  Binary compatibility is outwith the scope of the standard anyway.}

[447:5+1-3] NOTE 15.30,
            Delete entire note.
{Editorial (h) plus it contradicts the normative text.  The normative text
 requires the pointer to be a null pointer or the address of an array.  An
 array is an object!  Yes there are valid pointers in C that are not the
 address of an object, but the only obvious one is the "one byte past the
 end of an object value, which would not seem to make sense here anyway.}

[457:8+13] 15.10.2 Binding labels for procedures, NOTE 15.37,
           "may begin with an underscore"->"can begin with an underscore".
{Editorial (h).}

[458:1-1+18] 15.10.4 Asynchronous communication, p2 and NOTE 15.38,
  Append to p2
    "The restrictions for asynchronous input communication are the same as
     for asynchronous input data transfer.  The restrictions for
     asynchronous output communication are the same as for asynchronous
     output data transfer."
  and in the note,
    "may return" -> "can return".
    "executes" -> "can execute",
    delete "The restrictions ... input data transfer.",
    delete "The restrictions ... output data transfer.".
{Editorial (h), plus the statements about restrictions are better placed as
 normative text since they sound like requirements.}

[459:28,28+5-459:0+5] 16.2 Global identifiers, p2 and NOTE 16.2,
  Append to p2
    "A processor may assign a global identifier to an entity that is not
     specified by \thisstandard{} to have a global identifier (such as an
     intrinsic procedure); in such a case, the processor shall ensure that
     this assigned global identifier differs from all other global
     identifiers in the program.".
  and delete NOTE 16.2.
{Editorial (h) plus NOTE contains an actual requirement: Turn requirement
 buried in a note into normative text.  The remnants of the note are not
 interesting to the normal reader, but implementation advice for a Fortran
 processor vendor.  This advice is not needed.}

[461:15+2] 16.3.2 Local identifiers that are the same as common block
           names, NOTE 16.5,
           Delete entire note.
{Editorial (h) plus this is a trivial consequence of the normative text
 three lines earlier plus this is obsolescent anyway.  The alternative
 would be to change "may" to "can".}

[463:26+2] 16.5.1.2 Argument association, NOTE 16.6,
           "may be a nameless" -> "can be a nameless".
{Editorial (h).}

[465:14+2] 16.5.1.4 Host association, NOTE 16.9,
           "may contain the same" -> "can contain the same".
{Editorial (h).}

[467:16+2,7] 16.5.2.2 Pointer association status, NOTE 16.12,
             "may be accessible" -> "might be accessible",
             "shall not be used" -> "cannot be used".
{Editorial (h) plus unnecessary requirement.}

[477:32+2] 16.6.6 Events that cause variables to become undefined,
           NOTE 16.14,
           "may leave all" -> "could leave all".
{Editorial (h).}

[479:31] Annex A,
         Between "whether particular control characters"
         and "within a character literal constant",
         "may appear" -> "can appear".
{Editorial (h).  The entirety of the annexes is non-normative.}

[480:41] Annex A,
         After "whether particular control characters"
         "may appear" -> "can appear".
{Editorial (h).}

[486:33] B.3.2 Alternate return, p1,
         "may be replaced" -> "can be replaced".
{Editorial (h).}

[487:27] B.3.6 Assumed character length functions, p2,
         "may be assumed character length"
         ->"can have assumed character length".
{Editorial (h), plus "be" seems strange with this unhyphenated.}

[489:23] C.1.1 Selection of the approximation methods, p2,
         "may have flexibility in assigning such values and may add"
         ->"have flexibility in assigning such values and can add".
{Editorial (h).}

[489:29-30] C.1.2 Type extension and component accessibility, p1,
            "may be specified" -> "can be specified", TWICE.
{Editorial (h).}

[492:26,27,29] C.1.5 Pointers, p1,
               "may refer to" -> "can refer to",
               "may be considered" -> "might be imagined", TWICE,
               "may be changed" -> "can be changed".
{Editorial (h), plus "imagined" is a better verb for what this is
 describing than "considered".}

[492:32-33] C.1.5 Pointers, p2,
            "may have one" -> "can have one",
            "may have a" -> "can have a",
            "definition allows" -> "definition enables".
{Editorial (h), plus the definition is not permitting anything but enabling
 it.}

[493:22] C.1.6 Structure constructors and generic names, p1,
         "may be the same" -> "can be the same".
{Editorial (h).}

[494:8] C.1.6 Structure constructors and generic names, p2,
        "may still be used" -> "can still be used".
{Editorial (h).}

[497:3,4,5] C.2.1 The POINTER attribute, p1,
            "The POINTER attribute shall be specified to declare a pointer"
            ->"Specifying the POINTER attribute for an entity declares that
               it is a pointer",
            "may be specified" -> "can be specified",
            "may be associated" -> "can be associated".
{Editorial (h) plus impermissible usage of "shall".}

[499:29-30] C.3.1 Structure components, p2,
            "may be a data" -> "can be a data",
            "may be of" -> "can be of",
            "may be a scalar" -> "can be a scalar".
{Editorial (h).}

[500:5] C.3.1 Structure components, p3,
        "may be accessed" -> "can be accessed".
{Editorial (h).}

[501:33] C.3.3 Pointer allocation and association, p4,
         "may only be used" -> "can only be used".
{Editorial (h).}

[502:7] C.3.3 Pointer allocation and association, p5,
        "may be reused" -> "could be reused",
        "this is expedient" -> "it were expedient".
{Editorial (h) plus subjunctive.}

[502:10-12] C.4.1 Character assignment"
            Delete entire subclause.
{Editorial (h), plus this uninteresting minor change from Fortran 77 to
 Fortran 90 no longer needs any attention drawn to it.}

[502:14-16] C.4.2 Evaluation of function references, p1,
            "may be executed" -> "can be executed",
            "shall not depend" -> "cannot depend",
            "permits parallel execution" -> "enables parallel execution".
{Editorial (h).}

[505:18,22] C.6.1.1 File existence, p1 and p2,
            "may exclude files" -> "might exclude files".
            "may occur" -> "can occur".
{Editorial (h).}

[505:26] C.6.1.2 File access, p1,
         "may be part of" -> "might be part of".
{Editorial (h).}

[506:1-2] C.6.1.2 File access, p3,
          "may implement" -> "might implement",
          "might also" -> "might instead".
{Editorial (h).}

[506:7,10,11] C.6.1.3 File connection, p1,
              "may be performed" -> "can be performed",
              "shall be connected" -> "needs to be connected",
              "may be executed" -> "can be executed",
              "shall not be executed" -> "cannot be executed".
{Editorial (h).}

[506:13,17] C.6.1.4 FIle names, p1,
            "may have a name" -> "can have a name",
            "intended to allow" -> "intended to enable".
{Editorial (h).}

[507:12] C.6.2 Nonadvancing input/output, p8,
         "may read the entire" -> "could read the entire".
{Editorial (h).}

[507:30,32,35] C.6.3 OPEN statement, p1 and p2,
               "may become connected" -> "can become connected",
               "may be done" -> "could be done",
               "may be used" -> "can be used".
{Editorial (h).}

[508:1] C.6.3 OPEN statement, p3,
        "may become connected" -> "can become connected".
{Editorial (h).}

[508:4,5] C.6.3 OPEN statement, p4,
          "may also be used to create" -> "can also be used to create",
          "may be performed on a file" -> "can be performed on a file".
{Editorial (h).}

[508:10] C.6.3 OPEN statement, p5,
         "may be used to change" -> "can be used to change".
{Editorial (h).}

[508:12,15] C.6.3 OPEN statement, p6,
            "READ statements shall not" -> "a READ statement cannot",
            "may fail if the processor requires reading of"
            ->"might fail if the processor needs to read".
{Editorial (h) plus forbidden requirement plus singularisation plus
 wording improvement.}

[509:9-21] C.6.4 Connection properties, p1,
           "may be established" -> "are established",
           "a form may be established" -> "a form might be established",
           "a form may be delayed" -> "a form might be delayed",
           "length may be established" -> "length might be established",
           "An existing file with records that are not all of equal length
            shall not be connected for direct access."
           ->"A direct access file can only contain records that are all of
              equal length.",
           "If the access method is sequential, records of varying lengths
            are permitted."
           ->"A sequential file can contain records of varying lengths.".
{Editorial (h) plus forbidden requirements.  If any of these really are
 supposed to be requirements then someone should craft some text to go into
 Clause 9.}

[509:24,25] C.6.4 Connection properties, p2,
            "may require job control" -> "might need job control",
            "may require no job" -> "might be independently wealthy",
{Editorial (h).  Is this ancient cruft still useful?  I don't think so...}

[509:28,29] C.6.4 Connection properties, p3,
            "may include such things" -> "might include such things",
            "may occur upon" -> "might occur upon",
            Delete "It is a place ... Fortran.".
{Editorial (h).  But I think it is incredibly unlikely to include anything
 even remotely like mounting a tape, console messages, etc.  As for the
 last sentence, no it is not "a place".  In fact the whole paragraph would
 be better replaced by
    "The meaning of ``open'' in contexts other than Fortran is outwith the
     scope of the standard."
 with no further elaboration on the activities that are outside the scope.}

[509:34-510:2] C.6.5 CLOSE statement,
               Delete entire subclause.
{Editorial (h) plus
  - what's the "end of a run"?  I've never seen a computer jogging;
  - no, "This is" NOT a "place";
  - "is a permissible sequence of events" violates ISO guidelines;
  - "shall not deny" is a direct requirement which cannot be anywhere other
    than 9.5.7.
 If we really intend the requirement, someone needs to craft better words
 for insertion into 9.5.7.  Subclause C.6.5 is not the place for that, and
 there seems to be little reason for spending time crafting advice to
 vendors on how they might (or might not) extend the language.}

[510:10-11] C.6.6 Asynchronous input/output, p2,
            Delete final sentence "The documentation .. asynchronously.".
{Editorial (g).}

[510:24-26] C.6.6 Asynchronous input/output, p6,
            "This part of ISO/IEC 1539 allows a program to issue"
            -> "A program can issue",
            "It may be impossible ... individually."
            ->"That does not constitute a requirement for the processor to
               keep track of each individual request separately.".
{Editorial (h).}

[512:24-28] C.8.1 Main program and block data program unit, p2,
            Replace entire paragraph with
  "A processor might implement an unnamed program unit by assigning it a
   global identifier that is not used elsewhere in the program.  This
   could be done by using a default name that does not satisfy the rules
   for Fortran names.".
{Editorial (h).  This is already said better is normative text at the
 beginning of Clause 16.  Well, after the edits above anyway.}

[512:30,513:5-6] C.8.2 Dependent compilation, p1,
                 "is intended to permit" -> "is intended to enable",
                 "may be dependent" -> "can be dependent",
                 "may be that" -> "might be that",
                 "may depend on" -> "depends on".
{Editorial (h).  "enable" is pretty horrible here too, but at least it's
 not trying to give permission!}

[512:18,26] C.8.2 Dependent compilation, p2,
            "may change the interpretation"
            ->"could change the interpretation",
            "processor may be implemented"->"processor can be implemented".
{Editorial (h).}

[512:31] C.8.2 Dependent compilation, p3,
         "compilation shall be" -> "compilation be".
{Not really editorial (h), but still bad form to use "shall" like this.}

[514:4,6] C.8.2.1 USE statement and dependent compilation, p3,
          "may involve storing" -> "might involve storing",
          "Thus the processor may" -> "Thus the processor might".
{Editorial (h).}

[514:29,31] C.8.2.2 Accessibility attributes, p1,
            "information may be" -> "information might be",
            "it may be possible" -> "it might be possible", TWICE.
{Editorial (h).  Sounds more like pious hopes than useful information.}

[514:35-40] C.8.3.1 Identical common blocks,
            Delete entire subclause.
{Editorial (h), but we don't need this obsolescent coding guideline
 anyway.  Also the statements contained are untrue when the common block
 is initialised - the BLOCK DATA must have its own definition.  It's not
 worth weasel-wording this correctly.}

[515:2,10,11,13,15] C.8.3.2 Global data, throughout,
  "may contain only data" -> "could contain only data",
  "may have any combination" -> "can have any combination",
  "access to all of them may be made"->"access to all of them can be made",
  "conflicts may be made by" -> "conflicts can be made by, for example:".
{Editorial (h).}

[515:18] C.8.3.3 Derived types, p1,
         "may be defined" -> "can be defined".
{Editorial (h).}

[516:16-17] C.8.3.5 Procedure libraries, p1,
            "may be gathered into" -> "can be collected in",
            "an explicit" -> "an explicit interface".
{Editorial (h) plus tweak sentence plus fix typo.}

[516:31] C.8.3.5 Procedure libraries, p3,
  Change
    "This ... invoked:"
  to
    "This module provides an explicit interface that is necessary for
     subroutine LLS to be invoked, for example:"
{Editorial (h) plus mention that LLS needs an explicit interface.
 Otherwise the reader is left wondering what this is trying to convey.}

[516:37] C.8.3.5 Procedure libraries, p4,
         "may be constructed" -> "can be constructed".
{Editorial (h).}

[517:2-7] C.8.3.6 Operator extensions, throughout,
          "may be placed" -> "could be placed",
          "may be extended" -> "can be extended", TWICE,
          "may be defined" -> "can be defined".
{Editorial (h).}

[517:18] C.8.3.7 Data abstraction, p1,
         "Two sets may be checked" -> "Two sets can be checked".
{Editorial (h).}

[520:28-29] C.8.3.8 Public entities renamed, p1,
  After
    "At times"
  change
    "it may be"
  to
    "it might be".
{Editorial (h).}
  Delete "Care should ... USE statements.".
{Editorial (g).}

[520:31-521:3] C.8.3.8 Public entities renamed, p2 and p3,
               Unparagraph example p3, and indent 2cm,
               "and shall not be" -> "and cannot be".
{Editorial (h) plus typographical fixup.}

[525:13] C.9.1 Portability problems with external procedures, p1,
         "may be the name" -> "might be the name",
         "the processor would be permitted to interpret"
         ->"in such a case the processor would interpret".
{Editorial (h).}

[525:25-27] C.9.2 Procedures defined by means other than Fortran, p1,
  After
    "are considered"
  add
    "to be",
  Delete
    "The use of the term external should ... may be defined.".
{Editorial (g) and (h) in the same sentence, which is unnecessary witter
 anyway.  Improve readability of preceding sentence.}

[525:33-35] C.9.2 Procedures defined by means other than Fortran, p3,
            "may limit" -> "might limit",
            "may affect" -> "can affect",
            "might prohibit" -> "might not support".
{Editorial (h).}

[526:1-3] C.9.3 1 Abstract interfaces (12.4) and procedure pointer
          components, title, p1 and p2,
  Move embedded reference in the title to the end of it, viz
    "Abstract interfaces and procedure pointer components (12.4, 4.5)",
  Change
    "user may register" -> "user can register",
  Merge paragraph 2 into 1, i.e. the example should not be a paragraph.
{Editorial (h) plus typos.}

[528:2-3] C.9.4 Pointers and targets as arguments, p1,
  "may be a pointer" -> "could be a pointer",
  "may be a nonpointer" -> "could be a nonpointer".
  Delete "In either case... shall agree.".
{Editorial (h).}

[528:9-10] C.9.4 Pointers and targets as arguments, p1,
           "The actual argument shall ... INTENT(IN) attribute."
           ->"This only occurs when the actual argument has the TARGET
              attribute and the dummy argument has the INTENT (IN)
              attribute.".
{Editorial (h).}

[528:16,29] C.9.4 Pointers and targets as arguments, p3 and p4,
            Insert at the beginning of the paragraph
              "For example, consider:"
            Indent example by 2cm (not as a separate paragraph),
            Join paragraph 4 to paragraph 3.
{Typographical fixup.}

[528:31] C.9.4 Pointers and targets as arguments, p5,
         "This permits pointers" -> "This enables a pointer".
{Editorial (h) plus singularisation.}

[528:33,529:10] C.9.4 Pointers and targets as arguments, p6 and p7,
                Unparagraph p6 and indent example by 2cm,
                Unparagraph p7,
                i.e. p5-p7 is all one para with embedded example code.
{Typographical fixup.}

[531:20-21] C.9.6 Rules ensuring unambiguous generics, p8,
            "may be omitted" -> "can be omitted",
            "may be specified" -> "can be specified".
{Editorial (h).}

[535:6] C.10.1 Module for THIS IMAGE and IMAGE INDEX, p1,
        Change "COARRAY may ... needs"
        to     "they need".
{Editorial (h), plus a dummy argument being of any type has not been an
 obstacle to defining a procedure in Fortran for a decade now.}

[535:10-37] C.10.1 Module for THIS IMAGE and IMAGE INDEX, p3,
            Unparagraph and indent by 2cm.

[539:15] C.11.4 Example of calling C functions with noninteroperable data,
         p2,
         "This may be done" -> "This can be done".
{Editorial (h).  The wording of this sentence is still peculiar, but at
 least it will now not violate the ISO directives.}

[539:22] C.11.5 Example of opaque communication between C and Fortran,
         p1 and p2,
         "OO" -> "object-oriented",
         Unparagraph p2 (joining to p1) and indent 2cm.
{Spelling and typographical fixups.}

[540:6-8] C.11.5 Example of opaque communication between C and Fortran, p4,
           Unparagraph p4 (joining to p3) and indent 2cm.
{Typographical fixup.}

[540:10-541:1] C.11.5 Example of opaque communication between C and
               Fortran, p6,
               Unparagraph p6 (joining to p5) and indent 2cm.
{Typographical fixup.}

[547:27] C.11.10 Creating a contiguous copy of an array, p2,
         "The array itself may" -> "The array itself can".
{Editorial (h).  Yes it's a program comment.  It can still be right.}

[555:4,9-10] C.13.1.1 Whole array expressions and assignments, p1,
             "are permitted" -> "are provided",
             "may be arrays" -> "can be arrays",
             "may be generic" -> "can be generic",
             Delete "All arrays ... conforming array.".
{Editorial (h).  The deleted sentence is not just a forbidden requirement
 but is also factually wrong.  This is better stated in normative text.}

[555:14,18] C.13.1.2 Array sections, p1,
            "Whenever whole arrays may be used, ...``sections''"
            ->"As well as referencing or defining a whole array, it is also
               possible to reference or define a subarray.",
            "Of course, a common use may be" -> "One common use is".
{Editorial (h), plus the original opening sentence was factually incorrect,
 plus simplify the final sentence.}

[556:2,4,6,9,10] C.13.1.5 Array constructors, p1,
                 "Arrays ... exemplified by:"
                 ->"An array, and in particular an array constant, can be
                    constructed with an array constructor, for example:",
                 "which is a rank-one" -> "is a rank-one", TWICE,
                 "and contains the pair" -> "which contains the pair",
                 "Only rank-one arrays may be"
                 -> "Only a rank-one array can be",
                 "but higher-dimensional arrays may be made from them"
                 ->"but a higher-dimensional array can be made".
{Editorial (h) plus cleanup unnecessarily high literary quality
 ("exemplified" forsooth) and singularise.}

[556:17-18] C.13.2.1 Unconditional array computations, p1,
            "loops.  The loops were required"
            ->"loops that would otherwise be required".
{There is no context for "were" here.  Alternatively we could just delete
 the whole paragraph (and modify p2).}

[556:20-201] C.13.2.1 Unconditional array computations, p3 and p4,
             "may also be" -> "can also be",
             "if one makes use of" -> "using",
             "Thus, we can write" -> "For example,",
             Unparagraph p4 (joining to p3).
{Editorial (h) plus simplify.}

[557:16] C.13.2.2 Conditional array computations, p5,
         "we may write" -> "we can write".
{Editorial (h).  I don't like the style of this subclause at all.}

[557:26] C.13.2.3.1 Description of the model, p1,
         "The model may be" -> "The model can be".
{Editorial (h).}

[558:6] C.13.2.3.1 Description of the model, p3,
        "that may presumably lead" -> "that hopefully lead".
{Editorial (h), and this looks more hopeful than presumptive.}

[560:27] C.13.2.3.5 Reduction of storage, p1,
         "storage may be very important"
         -> "storage could be very important".
{Editorial (h).}

[563:12] C.13.6 Example of element-by-element computation, p1,
         "may be evaluated" -> "can be evaluated".
{Editorial (h).}

===END===