To: J3                                                     J3/18-221
From: Malcolm Cohen
Subject: Comment ** 078
Date: 2018-June-13


1. Introduction

"shall" is used to express a requirement
"should" is used to express a recommendation
"may" is used to express a permission
"can" is used to express a possibility
ISO/IEC Directives, Part 2, 2016, Clause 7

Please check all provisions to ensure that verbal
forms are used correctly
Verbal forms can also affect certain parts of the
document (i.e. Notes cannot contain requirements)


2. Response

Accepted.


3. Edit to N2146

Page 40, 5.3.2 Statement order, p1,
Change "may be interspersed" to "can be interspersed".
{Possibility not permission.}

Page 42, 5.3.7 Termination of execution, p2,
Change "also may be initiated" to "also can be initiated".
{Capability not permission.}

Same page, 5.4.1.2 Derived type, p1,
Change "may be parameterized" to "can be parameterized".
{Capability not permission.}

Page 43, same subclause, same paragraph,
Change "may be used" to "can be used".
Change "may appear" to "can appear"
{Possibility not permission.}.

Same page, 5.4.2 Data value, p1,
Change "may take" to "can take".
Change "may assume" to "can assume".
{Capability not permission.}

Same page, 5.4.3.2 Data object, p1,
Change "may be specified" to "can be specified".
{Possibility not permission.}

Same page, same subclause, p2
Change "may be referenced" to "can be referenced".
{Possibility not permission.}

Page 45, 5.4.6 Array, p1,
Delete "; the extents may be constant or may vary during execution"
(it's not interesting enough to wordsmith this to avoid using
 prohibited language).

Same page, same subclause, p2,
Change "may be performed simultaneously"
to "can be performed simultaneously".
{Capability not permission.}

Same page, same subclause, p3,
Change "may be constructed" to "can be constructed".
{Capability not permission.}

Same page, same subclause, p4,
Delete "may be of any type and".
(It is untrue that arrays are permitted to be of any type, e.g.
 "C824 An entity whose type has a coarray ultimate component shall be
       a nonpointer nonallocatable scalar.")

Page 47, 5.5.3 Other keywords, p2,
Change "may appear" to "can appear", twice.
{Possibility not permission - these are precisely the only places where
 the syntax has them, twice.}

Page 47, 5.5.7 Companion processors, p1,
Change "may be" to "can be" three times.
{These are possibilities, not permission.}
(Or if we think we need to give permission here,
 change "or may be" to "and may be".)

Page 50, 6.1.6 Other characters, p1,
Change "may appear only" to "shall only appear".
{This is a requirement, not permission.}

Page 53, 6.3.2.1 Free form line length, p1,
Change "may appear" to "can appear".
{The wording of this sentence makes this auxiliary into possibility,
 not permission.}
Change "it may contain" to "it shall contain".
{This is a requirement, not permission.}

Page 54, 6.3.3.1 General (in 6.3.3 Fixed source form), p1,
Change "may appear" to "can appear".
{This is definitively not permission.}

Page 55, 6.4 Including source text, p1,
Change "may be incorporated" to "can be incorporated".
{This is capability, not permission.}

Same page, same subclause, p4,
Change "may appear" to "can appear".
{This is not giving permission.}

Page 58, 7.2 Type parameters, p4,
Change "may be specified" to "can be specified".
{Capability, not permission.}

Same page, 7.3.1 Relationship of types and values to objects, p1,
Change "may be used" to "can be used".
Change "may be declared" to "can be declared".
{Both capability, not permission.}

Page 59, same subclause, p2,
Change "Scalar data of any intrinsic or derived type may be shaped in a
        rectangular pattern to compose an array of the same type and type
        parameters."
to "An array is formed of scalar data of an intrinsic or derived type, and
    has the same type and type parameters as its elements."
{Ugly, but it's not true that any type can make an array.
 The stuff about rectangular pattern is unnecessary and possibly wrong
 in the case of an assumed-size array.}

Same page, same subclause, p3,
Change "may take" to "can take".
{Possibility not permission.}
Same sentence, delete "of any type".
{It is not true that assignment can be used on variables of any type.}

Same page, same subclause, p4,
Change "may be used" to "can be used".
{Possibility not permission.}

Page 62, 7.4.3.1 Integer type, p5,
Change "may be represented" to "can be represented".
{Possibility not permission.}

Page 65, 7.4.4.2 Character type specifier, p3,
Change "By supplying nondefault character kinds,
        the processor may support additional character sets."
to "The processor may support additional character sets
    by supplying nondefault character kinds."
{Reword to make it permission.}

Page 75, 7.5.4.1 Component definition statement, p1,
Change "may be specified" to "can be specified", three times.
{Possibility not permission.}

Page 80, 7.5.4.8 Component accessibility, p1,
Change "may be explicitly" to "can be explicitly".
{Possibility not permission.}

Page 82, 7.5.5 Type-bound procedures, p5,
Change "may be identified" to "can be identified".
{Possibility not permission.}

Page 83, same subclause, p8,
Change "may be specified" to "can be specified".
{Possibility not permission.}

Page 87, 7.5.9 Derived-type specifier, C794,
Change "The keyword= may be omitted from a type-param-spec only if"
to "The keyword= shall not be omitted from a type-param-spec unless".
{Requirement not permission.}

Page 88, same subclause, C796,
Change "may be used as a type-param-value in a type-param-spec only in" to
  "shall not be used as a type-param-value in a type-param-spec except in"
{Requirement not permission.}

Same page, 7.5.10 Construction of derived-type values, C7101,
Change "may be omitted from a component-spec only if the keyword= has"
to "shall not be omitted from a component-spec unless the keyword= has".
{Requirement not permission.}

Page 95, 8.1 Attributes of procedures and data objects, p1,
Change "and may have" to "and can have".
{Possibility not permission.}

Same page, same subclause, same paragraph,
Change "All of its attributes may be specified"
to "The attributes listed in \ref{D5:Attributes} can be specified"
{Possibility not permission.  Also, it is far from clear that "other
 attributes" does not include things that cannot be declared in a type
 declaration statement, such as being a dummy argument or in an
 equivalence set.  The reference is to "8.5".}

Same page, same subclause, paragraphs 2 and 3,
change "and may have" to "and can have".
change "but may have" to "but can have".
{Possibility not permission.}

Page 96, 8.2 Type declaration statement, p2,
Change "may be specified or overridden" to "may be overridden", twice.
{The existing wording does not work as permission.}

Page 98, 8.5.4, ASYNCHRONOUS attribute, p1,
Change "that may" to ", and may".
{Current wording does not work for permission,
 and we want to give permission.}

Page 113, 8.6.7 DATA statement, p3,
Change "may appear in a subsequent type declaration only if"
to     "shall not appear in a subsequent type declaration unless".
{Requirement not permission.}

Page 123, 8.9 NAMELIST statement, p1,
Change "may be referred to" to "can be referred to".
{Capability not permission.}

Page 124, 8.10.1.2 Equivalence association, p1,
Change "and may cause" to "and can cause".
{Possibility not permission.}

Same page, 8.10.1.3 Equivalence of default character objects, p2,
Change "and may cause" to "and can cause".
{Possibility not permission.  I note that this duplicates 8.10.1,2p1
 and so could probably be deleted.}

Page 126, 8.10.2.4 Common association, p1,
Change "and may cause" to "and can cause".
{Possibility not permission.}

Page 130, 9.4.2 Structure components, p1,
Change "may be referenced" to "can be referenced".
{Capability not permission.}

Page 142, 9.7.1.4 Allocation of pointer targets, p1,
Change "may be used to reference" to "can be used to reference".
{Capability is more plausible than permission.}
Change "may become associated" to "can become associated".
{Capability is more plausible than permission.}
Change "may be used to determine" to "can be used to determine".
{Capability not permission.}

Page 153, 10.1.4 Evaluation of operations, p3,
Change "in any ac-implied-do it may contain"
to "in any ac-implied-do it contains".
{Simply wrong.}

Page 155, 10.1.5.2.4 Evaluation of numeric intrinsic operations, p3,
Change "may produce" to "can produce".
{Possibility not permission.}

Page 162, 10.1.8 Integrity of parentheses, p1,
Change "may evaluate" to "can evaluate".
{This is not giving permission - that was given elsewhere.}

Page 163, 10.1.9.2 Type, type parameters, and shape of a primary, p4,
Change "may appear as a primary only" to "shall appear as a primary only".
{Requirement not permission.}

Page 171, 10.2.2.1 General (in 10.2.2 Pointer assignment), p2,
Change "may also take place" to "can also take place".
{Possibility not permission.}

Page 181, 11.1.1 Blocks, p2,
Change "may be used" to "can be used".
{Capability not permission.}

Page 183, 11.1.4 BLOCK construct, p1,
Change "may contain" to "can contain".
{Possibility not permission.}

Page 204, 11.2.1 Branch concepts, p1,
Change "may be caused" to "can be caused".
{Capability not permission.}

Page 218, 12.2.3 Unformatted record, p1,
Change "may be read or written only" to "shall be read or written only".
{Requirement not permission.}

Same page, 12.2.4 Endfile record, p2,
Change "may occur only" to "shall occur only".
{Requirement not permission.}

Page 219, 12.3.3.2 Sequential access, p2,
Change "may be an endfile record" to "can be an endfile record".
{Possibility not permission.}

Page 220, 12.3.3.4 Stream access, p4,
Change "may contain record markers" to "can contain record markers".
{The grammar of this sentence makes it a statement of possibility,
 not giving permission.}

Page 222, 12.3.5 File storage units, p2,
Change "may be determined" to "can be determined".
{Capability not permission.}

Page 223, 12.4 Internal files, p2,
Change "A record may be read only if the record is defined."
to "A record shall be read only if the record is defined."
{Requirement not permission.}

Same page, same subclause, same paragraph, next bullet,
Change "A record of an internal file may become defined"
to "A record of an internal file can become defined",
and
"variable may become defined" to "variable can become defined".
{Possibility not permission.}

Page 225, 12.5.2 Connection modes, p4,
Change "may be changed" to "can be changed".
{Capability not permission.}

Same page, same subclause, p5,
Change "may be temporarily" to "can be temporarily".
{Possibility not permission.}

Page 226, 12.5.6.1 General, p1,
Change "may be used" to "can be used".
{Capability not permission.}

Page 227, 12.5.6.2 Syntax of the OPEN statement, p1,
Change "A specifier that requires a scalar-default-char-expr may have a
        limited list of character values."
to "Some specifiers that require a scalar-default-char-expr have a limited
    list of character values."
{Conditionality not permission, possibility, or capability.
 We could have simply changed "may" to "might", but ISO don't like "might"
 very much either.}

Page 233, 12.6.2.1 Syntax (in 12.6.2 Control information list), C1221,
Change "An ADVANCE= specifier may appear only in"
to     "An ADVANCE= specifier shall appear only in".
{Requirement not permission.}

Page 236, 12.6.2.11 POS= specifier in a data transfer statement, p1,
Change "may appear in a data transfer statement only if"
to     "shall not appear in a data transfer statement unless".
{Requirement not permission.}

Same page, 12.6.2.12 REC= specifier in a data transfer statement, p1,
Change "may appear only in" to "shall appear only in".
{Requirement not permission.
 Might be better to reword as "shall not... unless".}

Page 237, 12.6.3 Data transfer input/output list, p7,
Change (no element of that array) "may affect" to "shall affect",
and "nor may any element appear" to "nor shall any element appear".
{Requirement not permission.}

Page 250, 12.7.1 Wait operation, p1,
Change "A wait operation may be performed by"
to     "A wait operation can be performed by".
{Capability not permission.}

Page 252, 12.8.3 ENDFILE statement, p1,
Change "also may be" to "can also be"
{Capability not permission.}
and "only those records may be read" to "only those records shall be read"
{Requirement not permission.}

Same page, same subclause, p3,
change (only those file storage units) "may be subsequently read"
to "shall be subsequently read".
{Requirement not permission.}

Page 259, 12.10.2.30 SIZE= specifier in the INQUIRE statement, p2 and p3,
Change "may be connected" to "can be connected",
Twice.
{Capability not permission.}

Page 263, 12.12 Restrictions on input/output statements, p9,
Change "may become defined" to "might become defined".
{Conditionality not permission.}

Page 265, 13.1 Format specifications, p2,
Change "may refer to" to "can refer to",
and "alternatively may be" to "alternatively can be",
and "may be indicated" to "is indicated".
{Possibility not permission twice, and statement of fact not permission.}

Page 270, 13.7.1 Purpose of data edit descriptors, p1,
Change "may also cause" to "can also cause".
{Capability not permission.}

Page 271, 13.7.2.1 General rules, p1,
Change "may be used" to "can be used".
{Capability not permission.}

Page 283, 13.10.2 Values and value separators, p2,
Change "Neither of these forms may contain"
to     "Neither of these forms shall contain"
{Requirement not permission.}

Page 286, 13.10.4 List-directed output, p7,
Change "The end of a record may occur between the separator and
        the imaginary part only if"
to     "The end of a record shall not occur between the separator and
        the imaginary part unless"
{Requirement not permission.}

Page 289, 13.11.3.3 Namelist input values, p1,
Change "Neither of these forms may contain"
to     "Neither of these forms shall contain"
{Requirement not permission.}

Page 293, 14.1 Main program, C1401,
Change "The program-name may be included in the end-program-stmt only if"
to "The program-name shall not be included in the end-program-stmt unless"
{Requirement not permission.}

Page 298, 14.3 Block data program units, p3,
Replace entire paragraph
  "Only an object in a named common block may be initially defined in a
   block data program unit."
with
  "An object that is initially defined in a block data program unit shall
   be in a named common block."
{Requirement not permission. Rewrite for clarity.}

Page 299, 15.2.1 Procedure classification by reference, p2,
Change "may be referenced" to "can be referenced".
{Capability not permission.}

Page 301, 15.4.1 Interface and abstract interface, p1,
Change "may be invoked" to "can be invoked".
{Possibility not permission.}

Page 305, 15.4.3.4.2 Defined operations, p1,
Change "may be referenced" to "can be referenced".
{This is not giving permission.}

Page 306, 15.4.3.4.3 Defined assignments, p1,
Change "may be referenced" to "can be referenced".
{Ditto.}

Page 313, 15.5.2.1 Argument correspondence, p1,
Change "may be established" to "can be established".
{Possibility not permission.}

Page 321, 15.5.2.13 Restrictions on entities associated with dummy
          arguments, p1, item (4),
Change "may be referenced only" to "shall be referenced only".
{Requirement not permission.}

Page 337, 16.1 Classes of intrinsic procedures, p7,
Change "it may be referenced in the called procedure only with"
to     "it shall be referenced in the called procedure only with".
{Requirement not permission.}

Page 337, 16.2.1 General rules, p1,
Change "may be invoked" to "can be invoked".
{Capability not permission.}

Page 339, 16.3.1 General (in 16.3 Bit model), p2,
Change "may have the value 0 or 1" to "has the value 0 or 1".
{Not permission and no need for an auxiliary.}

Page 517, 19.5.2.2 Pointer association status, p1,
Change "A pointer may have"
(a pointer association status of associated, disassociated, or undefined.)
to     "A pointer has".
{This appears to be a statement of fact listing the entire set of possible
 pointer association statuses.}

Page 519, 19.5.2.7 Pointer definition status, p1,
Change
(If a pointer is associated with a definable target,)
"it may be defined or become undefined"
-> "it becomes defined or undefined"
(according to the rules for a variable).
{This should be specifying the rules, not giving someone permission!}

Page 520, 19.5.2.8 Relationship between association status and definition
          status, p1,
Change "always may be" to "may be".
{Not "always" because it might be an INTENT(IN) pointer.}

Page 521, 19.5.3.4 Association of scalar data objects, p8,
Change "partial association may occur only"
to     "partial association shall occur only",
Twice.
{Requirement not permission, twice.}

Page 539, B.1 Deleted features from Fortran 90, p2, item (6)
Change "it should be applied" to "it needs to be applied".
{Necessity not recommendation.}

===END===