CVS difference for ai12s/ai12-0444-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0444-1.txt

--- ai12s/ai12-0444-1.txt	2022/04/29 05:48:48	1.1
+++ ai12s/ai12-0444-1.txt	2022/05/04 00:03:04	1.2
@@ -1,12 +1,79 @@
-!standard 1.1.5(8)                                      22-04-27  AI12-0444-1/01
+!standard 1.1.5(8)                                      22-05-02  AI12-0444-1/02
+!standard 1.1.5(10)
+!standard 2.1(4/5)
+!standard 3.5.4(5)
+!standard 3.5.4(24)
+!standard 3.5.4(25)
 !standard 3.5.4(26)
 !standard 3.5.6(7/5)
 !standard 3.5.6(8/5)
+!standard 3.5.7(5)
+!standard 3.5.7(16)
+!standard 3.6(15)
+!standard 3.9.3(6/4)
+!standard 6.1.2(41/5)
+!standard 6.3(4)
+!standard 7.4(8/3)
+!standard 7.6(19/3)
+!standard 7.6(21/3)
+!standard 9.5.3(22)
+!standard 9.5.3(23/4)
 !standard 9.5.3(25)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
+!standard 9.6(31)
+!standard 9.8(3)
+!standard 9.10.1(25/5)
+!standard 10.1.3(11)
+!standard 10.2.1(11.2/5)
+!standard 11.4.2(27/3)
+!standard 11.6(5)
+!standard 13.1(22/3)
+!standard 13.1(23/5)
+!standard 13.1(24/3)
+!standard 13.1(25/3)
+!standard 13.1(26/3)
+!standard 13.1(27/3)
+!standard 13.1(28/3)
+!standard 13.2(8/4)
+!standard 13.3(29/2)
+!standard 13.3(30/2)
+!standard 13.3(30.1/2)
+!standard 13.3(33.2/2)
+!standard 13.3(51.2/2)
+!standard 13.3(51.3/2)
+!standard 13.3(65)
+!standard 13.4(10)
+!standard 13.5.1(22)
+!standard 13.11(25.4/2)
+!standard 13.12.1(7/2)
+!standard 13.13.1(36/5)
+!standard A.4.12(1/5)
+!standard A.5.1(48)
+!standard A.10(8)
+!standard A.10.8(23)
+!standard A.10.9(36)
+!standard A.10.9(37)
+!standard A.13(16)
+!standard B.1(41/4)
+!standard B.3(62.1/3)
+!standard C.3.2(24/5)
+!standard C.7.2(28)
+!standard D.2.2(17/2)
+!standard D.2.2(18/2)
+!standard D.3(15/2)
+!standard D.4(15/2)
+!standard D.4.1(8/5)
+!standard D.11(10)
+!standard D.14(28/2)
+!standard E.1(13)
+!standard E.2.3(20/5)
+!standard E.5(27)
+!standard G.1.1(54)
+!standard G.1.2(46)
+!standard G.2(3)
+!standard G.3.1(87/2)
+!standard G.3.1(156/2)
+!standard G.3.1(157/2)
+!standard H.7.1(14/5)
 !class presentation 22-04-27
 !status work item 22-04-27
 !status received 22-02-18
@@ -30,7 +97,7 @@
 
 !recommendation
 
-Reword all wording including "need not", perferably into a positive statement.
+Reword all wording including "need not", preferably into a positive statement.
 Non-normative material like notes and examples including "need not" are
 handled in AI12-0442-1; a single case is found in AI12-0438-1 as the paragraph
 also includes "must"; the rest are found here.
@@ -47,6 +114,31 @@
     but in any case one possible effect of a bounded error is the raising
     of the exception Program_Error.
 
+Modify 1.1.5(10):
+
+    In addition to bounded errors, the language rules define certain kinds
+    of errors as leading to erroneous execution. Like bounded errors, the
+    implementation {is not expected to}[need not] detect such errors 
+    either prior to or during run time. Unlike bounded errors, there is no
+    language-specified bound on the possible effect of erroneous execution;
+    the effect is in general not predictable.
+
+Modify 2.1(4/5):
+
+    The coded representation for characters is implementation defined (it
+    {can}[need not] be a representation {that is not} defined within 
+    ISO/IEC 10646:2017). A character whose relative code point in its plane
+    is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program.
+    The only characters allowed outside of comments are those in categories
+    other_format, format_effector, and graphic_character.
+
+Modify 3.5.4(5):
+
+    Each simple_expression in a signed_integer_type_definition is expected to
+    be of any integer type; they [need not be of the same]{can be of different
+    integer} type{s}. The expression in a modular_type_definition is likewise
+    expected to be of any integer type.
+
 Modify 3.5.4(24):
 
     For the execution of a predefined operation of a signed integer type, {it
@@ -63,6 +155,21 @@
     required} if the result is outside the base range of the type,
     {unless}[so long as] the correct result is produced.
 
+Modify 3.5.4(25):
+
+    An implementation may provide additional predefined signed integer types,
+    declared in the visible part of Standard, whose first subtypes have names
+    of the form Short_Integer, Long_Integer, Short_Short_Integer,
+    Long_Long_Integer, etc. Different predefined integer types are allowed to
+    have the same base range. However, the range of Integer should be no wider
+    than that of Long_Integer. Similarly, the range of Short_Integer (if
+    provided) should be no wider than Integer. Corresponding recommendations
+    apply to any other predefined integer types. [There need not be a named 
+    integer type corresponding to each distinct]{An implementation may support}
+    base range{s} [supported by an implementation] for which there is no
+    corresponding named integer type}. The range of each first subtype should
+    be the base range of its type.
+
 Modify 3.5.4(26):
 
    An implementation may provide nonstandard integer types, descendants of
@@ -120,732 +227,654 @@
    explicit_generic_actual_parameters for formal scalar types - see 12.5.2.
 
 [See 3.5.4(26) for comments - Editor.]
-
-Modify 9.5.3(25):
-
-   When an attempt is made to cancel an entry call, the implementation {does not
-   have to}[need not] make the attempt using the thread of control of the task
-   (or interrupt) that initiated the cancellation; in particular, it may use
-   the thread of control of the caller itself to attempt the cancellation, even
-   if this {can}[might] allow the entry call to be selected in the interim.
-
-["need not" is replaced by other wording. Also "might" is changed to 
-"can". - Editor.]
-
-[*** TBD: A large number of remaining paragraphs that still need wording
-proposals are found at the start of the !appendix - Editor.]
-
-!discussion
-
-To summarize the ISO rules from the Directives part 2 (often referred to as the
-drafting standard):
-
-Requirements use "shall" preferably, or phrases involving forms of "require",
-"has to", or "it is necessary". "Must" is not allowed (it can be
-used for external requirements, such as government laws, but that usually
-doesn't apply to us).
-
-Recommendations use "should" preferably, or phrases involving forms of
-"recommend" or "ought to".
-
-Permissions should use "may" preferably, or phrases using forms of "permit" or
-"allow". "Might" is not allowed in this context. Negative forms are not
-allowed (no "may not"); permissions must be positive. A quote: "Rather than
-using negative permissions, either rewrite the sentence to state what is
-permitted, or rewrite as a requirement/recommendation not to do something."
-
-Possibility should use "can", or phrases using forms of "able" or "possible".
-
-ISO has taken this further and does not want to see "might", "could", or
-"need" at all; they assume that they are being used in one of the above
-contexts. I don't know where "need" comes from (other than the "House Style",
-but that's not normative), the Directives never mentions it as a word
-to avoid, and in fact it uses the word "needs" with the meaning of desires
-repeatedly. But the Directives is clear that one should not use any
-words other than the above to express requirements, recommendations, or
-permissions.
-
-Note that while some phrases are given meanings, other uses of the words seem
-be to be allowed by the Directives. For instance, "necessary" is used in many
-contexts in the Directives that are not requirements.
-
-We have a particular problem with "need not", used frequently to get around
-not being able to say "may not". But negative permissions aren't allowed at
-all, in any verbal form. (They have to be reworded positively, or integrated
-into the requirements if that's not possible.) This is a problem since many
-of our permissions are exceptions to rules stated elsewhere, and those have
-to be written negatively. We handle just this problem in this AI; other
-wording changes needed are handled in AI12-0438-1, AI12-0439-1, and AI12-0445-1.
-
---
-
-We could consider making wording changes only for the ISO version (new
-commands would be needed in the formatter to support that if is done a lot
- - currently, we can only do that on a full paragraph basis or with a few 
-macros - but new commands should not be hard to define and implement).
-
-However, that would add complications to future maintenance (as we would need
-to somehow have both versions in any Corrigendum document, one for our use and
-one for the actual ISO Corrigendum). As such, we want to make any changes that
-do not clearly alter the meaning or harm the understandability of the text.
-
-!ASIS
-
-No ASIS effect.
-
-!ACATS test
-
-No ACATS test should be needed, no change in meaning is intended and these
-are notes anyway.
-
-!appendix
-
-Below here are wording changes for "need not", ..., that need complete rewrites:
-
-1.1.5 
-
-10      In addition to bounded errors, the language rules define certain kinds
-        of errors as leading to erroneous execution. Like bounded errors, the
-        implementation {is not expected to}[need not] detect such errors 
-        either prior to or during
-        run time. Unlike bounded errors, there is no language-specified bound
-        on the possible effect of erroneous execution; the effect is in
-        general not predictable.
-
-[No attempt to fix.]
-
-2.1 Character Set
-
-4/5 The coded representation for characters is implementation defined (it need
-not be a representation defined within ISO/IEC 10646:2017). A character whose
-relative code point in its plane is 16#FFFE# or 16#FFFF# is not allowed
-anywhere in the text of a program. The only characters allowed outside of
-comments are those in categories other_format, format_effector, and
-graphic_character.
-
-[No attempt to fix.]
-
-3.5.4 Integer Types
-
-5   Each simple_expression in a signed_integer_type_definition is expected to
-be of any integer type; they need not be of the same type. The expression in a
-modular_type_definition is likewise expected to be of any integer type.
-
-[No attempt to fix.]
-
-25  An implementation may provide additional predefined signed integer types,
-declared in the visible part of Standard, whose first subtypes have names of
-the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer,
-etc. Different predefined integer types are allowed to have the same base
-range. However, the range of Integer should be no wider than that of
-Long_Integer. Similarly, the range of Short_Integer (if provided) should be no
-wider than Integer. Corresponding recommendations apply to any other
-predefined integer types. There need not be a named integer type corresponding
-to each distinct base range supported by an implementation. The range of each
-first subtype should be the base range of its type.
 
-[No attempt to fix.]
+Modify 3.5.7(5):
 
-3.5.7 Floating Point Types
+   Each simple_expression of a real_range_specification is expected to be of
+   any real type; the types {can} [need not] be [the same]{different}.
 
-5   Each simple_expression of a real_range_specification is expected to be of
-any real type; the types need not be the same.
+Modify 3.5.7(16):
 
-[No attempt to fix.]
+   An implementation is allowed to provide additional predefined floating
+   point types, declared in the visible part of Standard, whose (unconstrained)
+   first subtypes have names of the form Short_Float, Long_Float,
+   Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
+   types are allowed to have the same base decimal precision. However, the
+   precision of Float should be no greater than that of Long_Float. Similarly,
+   the precision of Short_Float (if provided) should be no greater than Float.
+   Corresponding recommendations apply to any other predefined floating point
+   types. [There need not be a named floating point type corresponding to each
+   distinct]{An implementation may support} base decimal precision{s for which
+   there is no corresponding named floating point type} [supported by an
+   implementation].
+
+Modify 3.6(15):
+
+   An unconstrained_array_definition defines an array type with an
+   unconstrained first subtype. Each index_subtype_definition defines the
+   corresponding index subtype to be the subtype denoted by the subtype_mark.
+   The compound delimiter <> (called a box) of an index_subtype_definition
+   stands for an undefined range (different objects of the type [need 
+   not]{can} have [the same] {different} bounds).
+
+Modify 3.9.3(6/4):
+
+  * Otherwise, the subprogram shall be overridden with a nonabstract
+    subprogram or, in the case of a private extension inheriting a
+    nonabstract function with a controlling result, have a full type that
+    is a null extension; for a type declared in the visible part of a
+    package, the overriding may be either in the visible or the private
+    part. Such a subprogram is said to require overriding. However, if the
+    type is a generic formal type, the subprogram {is allowed to be inherited
+    as is, without being} [need not be] overridden for the formal type itself;
+    a nonabstract version will necessarily be provided by the actual type.
+
+Modify 6.1.2(41/5):
+
+    An implementation [need not require that all]{can allow some} references
+    to a constant object [be]{which are not} accounted for by the Global or
+    Global'Class aspect when it is considered a variable in the above rules{,}
+    if the implementation can determine that the object is in fact immutable.
+
+Modify 6.3(4):
+
+    In contrast to other bodies, a subprogram_body {is allowed to be defined 
+    without it being} [need not be] the completion of a previous declaration,
+    in which case the body declares the subprogram. If the body is a
+    completion, it shall be the completion of a subprogram_declaration or
+    generic_subprogram_declaration. The profile of a subprogram_body that 
+    completes a declaration shall conform fully to that of the declaration.
+
+Modify 7.4(8/3):
+
+    A deferred constant declaration for which the Import aspect is True [need
+    not]{can} appear [in the visible part of a package_specification]{anywhere
+    that an object_declaration is allowed}, and has no full constant
+    declaration.
+
+Modify 7.6(19/3):
+
+  * If an object is assigned the value of that same object, the
+    implementation [need not do anything]{may omit the assignment}.
+
+Modify 7.6(21/3):
+
+  * The implementation [need not create]{may avoid creating} an anonymous 
+    object if the value being assigned is the result of evaluating a name 
+    denoting an object (the source object) whose storage cannot overlap with
+    the target. If the source object [might]{can} overlap with the target
+    object, then the implementation can avoid the need for an intermediary
+    anonymous object by exercising one of the above permissions and perform
+    the assignment one component at a time (for an overlapping array
+    assignment), or not at all (for an assignment where the target and the
+    source of the assignment are the same object).
+
+["need not", bonus "might" - Editor.]
+
+Modify 9.5.3(22):
+
+    An implementation may perform the sequence of steps of a protected action
+    using any thread of control; it [need not be]{can be a thread other than}
+    that of the task that started the protected action. If an entry_body
+    completes without requeuing, then the corresponding calling task may be
+    made ready without waiting for the entire protected action to complete.
+
+Modify 9.5.3(23/4):
+
+    When the entry of a protected object is checked to see whether it is
+    open, the implementation [need not reevaluate]{can bypass reevaluating}
+    the condition of the corresponding entry_barrier if no variable or 
+    attribute referenced by the condition (directly or indirectly) has been
+    altered by the execution (or cancellation) of a call to an exclusive
+    protected operation of the object since the condition was last evaluated.
 
-16  An implementation is allowed to provide additional predefined floating
-point types, declared in the visible part of Standard, whose (unconstrained)
-first subtypes have names of the form Short_Float, Long_Float,
-Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
-types are allowed to have the same base decimal precision. However, the
-precision of Float should be no greater than that of Long_Float. Similarly,
-the precision of Short_Float (if provided) should be no greater than Float.
-Corresponding recommendations apply to any other predefined floating point
-types. There need not be a named floating point type corresponding to each
-distinct base decimal precision supported by an implementation.
-
-[No attempt to fix.]
-
-3.6 Array Types
-
-15  An unconstrained_array_definition defines an array type with an
-unconstrained first subtype. Each index_subtype_definition defines the
-corresponding index subtype to be the subtype denoted by the subtype_mark. The
-compound delimiter <> (called a box) of an index_subtype_definition stands for
-an undefined range (different objects of the type need not have the same
-bounds).
-
-[No attempt to fix.]
-
-3.9.3 Abstract Types and Subprograms
-
-6/4   * Otherwise, the subprogram shall be overridden with a nonabstract
-        subprogram or, in the case of a private extension inheriting a
-        nonabstract function with a controlling result, have a full type that
-        is a null extension; for a type declared in the visible part of a
-        package, the overriding may be either in the visible or the private
-        part. Such a subprogram is said to require overriding. However, if the
-        type is a generic formal type, the subprogram {does not have to
-        be}[need not] be overridden
-        for the formal type itself; a nonabstract version will necessarily be
-        provided by the actual type.
-
-[Note that negative Requirements are OK, only negative permissions are not allowed.]
-
-6.1.2 The Global and Global'Class Aspects
-
-41/5 An implementation need not require that all references to a constant
-object be accounted for by the Global or Global'Class aspect when it is
-considered a variable in the above rules if the implementation can determine
-that the object is in fact immutable.
-
-[No attempt to fix.]
-
-6.3 Subprogram Bodies
-
-4   In contrast to other bodies, a subprogram_body need not be the completion
-of a previous declaration, in which case the body declares the subprogram. If
-the body is a completion, it shall be the completion of a
-subprogram_declaration or generic_subprogram_declaration. The profile of a
-subprogram_body that completes a declaration shall conform fully to that of
-the declaration.
-
-[No attempt to fix.]
-
-7.4 Deferred Constants
-
-8/3 A deferred constant declaration for which the Import aspect is True need
-not appear in the visible part of a package_specification, and has no full
-constant declaration.
-
-[No attempt to fix.]
-
-7.6    Assignment and Finalization
-
-19/3   * If an object is assigned the value of that same object, the
-        implementation need not do anything.
-
-[No attempt to fix.]
-
-21/3   * The implementation need not create an anonymous object if the value
-        being assigned is the result of evaluating a name denoting an object
-        (the source object) whose storage cannot overlap with the target. If
-        the source object might overlap with the target object, then the
-        implementation can avoid the need for an intermediary anonymous object
-        by exercising one of the above permissions and perform the assignment
-        one component at a time (for an overlapping array assignment), or not
-        at all (for an assignment where the target and the source of the
-        assignment are the same object).
-
-["need not", bonus "might". The "might" should be "can", especially as the 
-previous line uses "cannot". But no idea for "need not".]
-
-9.5.3 Entry Calls
-
-22  An implementation may perform the sequence of steps of a protected action
-using any thread of control; it need not be that of the task that started the
-protected action. If an entry_body completes without requeuing, then the
-corresponding calling task may be made ready without waiting for the entire
-protected action to complete.
-
-[No attempt to fix.]
-
-23/4 When the entry of a protected object is checked to see whether it is
-open, the implementation need not reevaluate the condition of the
-corresponding entry_barrier if no variable or attribute referenced by the
-condition (directly or indirectly) has been altered by the execution (or
-cancellation) of a call to an exclusive protected operation of the object
-since the condition was last evaluated.
-
-[No attempt to fix.]
-
-9.6 Delay Statements, Duration, and Time
-
-31  The time base for delay_relative_statements should be monotonic; it need
-not be the same time base as used for Calendar.Clock.
-
-[No attempt to fix.]
-
-9.8 Abort of a Task - Abort of a Sequence of Statements
-
-3   Each task_name is expected to be of any task type; they need not all be of
-the same task type.
-
-[No attempt to fix.]
-
-9.10.1 Conflict Check Policies
-
-25/5            Specifying the Parallel_Calls aspect to be True for a
-                subprogram indicates that the subprogram can be safely called
-                in parallel. Conflict checks (if required by the
-                Conflict_Check_Policy in effect) are made on the subprogram
-                assuming that multiple concurrent calls exist. Such checks
-                need not be repeated at each call of the subprogram in a
-                parallel iteration context.
-
-[No attempt to fix.]
-
-10.1.3 Subunits of Compilation Units
+Modify 9.5.3(25):
 
-11  In contrast, a subprogram_body_stub need not be the completion of a
-previous declaration, in which case the _stub declares the subprogram. If the
-_stub is a completion, it shall be the completion of a
-subprogram_declaration or generic_subprogram_declaration. The profile of a
-subprogram_body_stub that completes a declaration shall conform fully to that
-of the declaration.
+   When an attempt is made to cancel an entry call, the implementation {can 
+   use a}[need not make the attempt using the] thread of control {other than 
+   that} of the task (or interrupt) that initiated the cancellation; in
+   particular, it may use the thread of control of the caller itself to
+   attempt the cancellation, even if this {can}[might] allow the entry call
+   to be selected in the interim.
 
-[No attempt to fix.]
+["need not" is replaced by other wording. Also "might" is changed to 
+"can". - Editor.]
 
-10.2.1 Elaboration Control
+Modify 9.6(31):
 
-11.2/5   * The partial view of a private type or private extension, a
-        protected type without entry_declarations, a generic formal private
-        type, or a generic formal derived type, has preelaborable
-        initialization if and only if the Preelaborable_Initialization aspect
-        has been specified True for them. A protected type with
-        entry_declarations or a task type never has preelaborable
-        initialization. The Preelaborable_Initialization aspect of a partial
-        view of a type may be specified as False, even if the full view of the
-        type has preelaborable initialization. Similarly, a generic formal
-        type need not be specified to have preelaborable initialization, even
-        if the actual type in an instance has preelaborable initialization.
+   The time base for delay_relative_statements should be monotonic; it {can
+   be different than}[need not be] the [same] time base as used for
+   Calendar.Clock.
 
-[No attempt to fix.]
+Modify 9.8(3):
 
-11.4.2 Pragmas Assert and Assertion_Policy
+   Each task_name is expected to be of any task type; [they need not all be of
+   the same]{each can be of a different} task type.
 
-27/3 An implementation need not allow the specification of an assertion
-expression if the evaluation of the expression has a side effect such that an
-immediate reevaluation of the expression could produce a different value.
-Similarly, an implementation need not allow the specification of an assertion
-expression that is checked as part of a call on or return from a callable
-entity C, if the evaluation of the expression has a side effect such that the
-evaluation of some other assertion expression associated with the same call of
-(or return from) C could produce a different value than it would if the first
-expression had not been evaluated.
+Modify 9.10.1(25/5):
 
-[Multiple "need not allow"; two bonus "could"s too. No idea of a fix.]
+    Specifying the Parallel_Calls aspect to be True for a
+    subprogram indicates that the subprogram can be safely called
+    in parallel. Conflict checks (if required by the
+    Conflict_Check_Policy in effect) are made on the subprogram
+    assuming that multiple concurrent calls exist. Such checks
+    [need not be repeated at each]{can then be omitted on a} call of the 
+    subprogram in a parallel iteration context.
 
-[No attempt to fix.]
+Modify 10.1.3(11):
 
-11.6 Exceptions and Optimization
+    In contrast, a subprogram_body_stub [need not be]{can be defined without
+    it being} the completion of a previous declaration, in which case the
+    _stub declares the subprogram. If the _stub is a completion, it shall be
+    the completion of a subprogram_declaration or
+    generic_subprogram_declaration. The profile of a subprogram_body_stub that
+    completes a declaration shall conform fully to that of the declaration.
 
-5     * An implementation need not always raise an exception when a
-        language-defined check fails. Instead, the operation that failed the
-        check can simply yield an undefined result. The exception need be
-        raised by the implementation only if, in the absence of raising it,
-        the value of this undefined result would have some effect on the
-        external interactions of the program. In determining this, the
-        implementation shall not presume that an undefined result has a value
-        that belongs to its subtype, nor even to the base range of its type,
-        if scalar. Having removed the raise of the exception, the canonical
-        semantics will in general allow the implementation to omit the code
-        for the check, and some or all of the operation itself.
+Modify 10.2.1(11.2/5):
 
-[No attempt to fix. Fix "need be", too.]
+   * The partial view of a private type or private extension, a
+     protected type without entry_declarations, a generic formal private
+     type, or a generic formal derived type, has preelaborable
+     initialization if and only if the Preelaborable_Initialization aspect
+     has been specified True for them. A protected type with
+     entry_declarations or a task type never has preelaborable
+     initialization. The Preelaborable_Initialization aspect of a partial
+     view of a type may be specified as False, even if the full view of the
+     type has preelaborable initialization. Similarly, a generic formal
+     type [need not]{may} be specified [to have preelaborable 
+     initialization]{with Preelaborable_Initialization False}, even
+     if the actual type in an instance has preelaborable initialization.
 
-12.5.1 Formal Private and Derived Types
+Modify 11.4.2(27/3):
 
-15  For a generic formal type with an unknown_discriminant_part, the actual
-may, but need not, have discriminants, and may be definite or indefinite.
+    An implementation [need not allow]{may disallow} the specification of an
+    assertion expression if the evaluation of the expression has a side effect
+    such that an immediate reevaluation of the expression {can}[could] produce
+    a different value. Similarly, an implementation [need not allow]{may
+    disallow} the specification of an assertion expression that is checked as
+    part of a call on or return from a callable entity C, if the evaluation of
+    the expression has a side effect such that the evaluation of some other
+    assertion expression associated with the same call of (or return from) C
+    {can}[could] produce a different value than [it would if]{in the case when}
+    the first expression had not been evaluated.
 
-[No attempt to fix. "(but discriminants are not required)"??]
+[Multiple "need not allow"; two bonus "could"s too - Editor.]
 
-13.1 Operational and Representation Aspects
+Modify 11.6(5):
 
-22/3   * An implementation need not support the specification for a
-        representation aspect that contains nonstatic expressions, unless each
-        nonstatic expression is a name that statically denotes a constant
-        declared before the entity.
+  * An implementation {can omit raising}[need not always raise] an exception
+    when a language-defined check fails. Instead, the operation that failed
+    the check can simply yield an undefined result. The exception {is
+    required to be}[need be] raised by the implementation only if, in the
+    absence of raising it, the value of this undefined result would have
+    some effect on the external interactions of the program. In determining
+    this, the implementation shall not presume that an undefined result has
+    a value that belongs to its subtype, nor even to the base range of its
+    type, if scalar. Having removed the raise of the exception, the canonical
+    semantics will in general allow the implementation to omit the code
+    for the check, and some or all of the operation itself.
 
-["need not support". No idea of a fix.]
+[Replace "need not" and "need be".]
 
-23/5   * An implementation need not support a specification for the
-        Object_Size or Size for a given composite subtype, nor the size or
-        storage place for an object (including a component) of a given
-        composite subtype, unless the constraints on the subtype and its
-        composite subcomponents (if any) are all static constraints.
+Modify 12.5.1(15):
 
-["need not support". No idea of a fix.]
+    For a generic formal type with an unknown_discriminant_part, the actual
+    may[, but need not,] have discriminants{, though that is not required}, 
+    and may be definite or indefinite.
 
-24/3   * An implementation need not support specifying a nonconfirming
-        representation aspect value if it could cause an aliased object or an
-        object of a by-reference type to be allocated at a nonaddressable
-        location or, when the alignment attribute of the subtype of such an
-        object is nonzero, at an address that is not an integral multiple of
-        that alignment.
+Modify 13.1(22/3):
 
-["need not support", "could cause". No idea of a fix.]
+  * An implementation {is not required to}[need not] support the
+    specification for a representation aspect that contains nonstatic
+    expressions, unless each nonstatic expression is a name that
+    statically denotes a constant declared before the entity.
 
-25/3   * An implementation need not support specifying a nonconfirming
-        representation aspect value if it could cause an aliased object of an
-        elementary type to have a size other than that which would have been
-        chosen by default.
+[We tried a large number of rewordings here; this was the easiest that seems
+that it might be OK. For the 13.1 wording, I had suggested "never" rather than
+"not", to emphasize that these are the most important rules and they apply
+even when the Recommended Level of Support is required. Tuck thought that was
+overkill.
 
-["need not support", "could cause". No idea of a fix.]
+Other ideas included "may disallow" and "support is optional" - Editor.]
 
-26/3   * An implementation need not support specifying a nonconfirming
-        representation aspect value if it could cause an aliased object of a
-        composite type, or an object whose type is by-reference, to have a
-        size smaller than that which would have been chosen by default.
+Modify 13.1(23/5):
 
-["need not support", "could cause". No idea of a fix.]
+  * An implementation {is not required to}[need not] support a specification
+    for the Object_Size or Size for a given composite subtype, nor the size or
+    storage place for an object (including a component) of a given
+    composite subtype, unless the constraints on the subtype and its
+    composite subcomponents (if any) are all static constraints.
 
-27/3   * An implementation need not support specifying a nonconfirming
-        subtype-specific representation aspect value for an indefinite or
-        abstract subtype.
+Modify 13.1(24/3):
 
-["need not support". No idea of a fix.]
+  * An implementation {is not required to}[need not] support specifying a
+    nonconfirming representation aspect value if it [could]{can} cause an
+    aliased object or an object of a by-reference type to be allocated at
+    a nonaddressable location or, when the alignment attribute of the subtype
+    of such an object is nonzero, at an address that is not an integral 
+    multiple of that alignment.
 
-28/3 For purposes of these rules, the determination of whether specifying a
-representation aspect value for a type could cause an object to have some
-property is based solely on the properties of the type itself, not on any
-available information about how the type is used. In particular, it presumes
-that minimally aligned objects of this type might be declared at some point.
+[Replace "need not support", "could cause" - Editor.]
 
-["could cause"; that is used sort of like a technical term, but it isn't
-a defined term and even if it was, it's not clear it would be allowed.
-"might" also occurs here.]
+Modify 13.1(25/3):
 
-13.2 Packed Types
+  * An implementation {is not required to}[need not] support specifying a
+    nonconfirming representation aspect value if it [could]{can} cause an
+    aliased object of an elementary type to have a size other than that
+    which would have been chosen by default.
 
-8/4   * For a packed record type, the components should be packed as tightly
-        as possible subject to the above alignment requirements, the Sizes of
-        the component subtypes, and any record_representation_clause that
-        applies to the type; the implementation may, but need not, reorder
-        components or cross aligned word boundaries to improve the packing. A
-        component whose Size is greater than the word size may be allocated an
-        integral number of words.
+[Replace "need not support", "could cause" - Editor.]
 
-[No attempt to fix.]
+Modify 13.1(26/3):
 
-13.3 Operational and Representation Attributes
+  * An implementation {is not required to}[need not] support specifying a
+    nonconfirming representation aspect value if it [could]{can} cause an
+    aliased object of a composite type, or an object whose type is
+    by-reference, to have a size smaller than that which would have been
+    chosen by default.
 
-29/2   * An implementation need not support an Alignment clause for a signed
-        integer type specifying an Alignment greater than the largest
-        Alignment value that is ever chosen by default by the implementation
-        for any signed integer type. A corresponding limitation may be imposed
-        for modular integer types, fixed point types, enumeration types,
-        record types, and array types.
+[Replace "need not support", "could cause" - Editor.]
 
-["need not support". No idea of a fix.]
+Modify 13.1(27/3):
 
-30/2   * An implementation need not support a nonconfirming Alignment clause
-        which could enable the creation of an object of an elementary type
-        which cannot be easily loaded and stored by available machine
-        instructions.
+  * An implementation {is not required to}[need not] support specifying a 
+    nonconfirming subtype-specific representation aspect value for an
+    indefinite or abstract subtype.
 
-["need not support", "could enable". No idea of a fix.]
+Modify 13.1(28/3):
 
-30.1/2   * An implementation need not support an Alignment specified for a
-        derived tagged type which is not a multiple of the Alignment of the
-        parent type. An implementation need not support a nonconfirming
-        Alignment specified for a derived untagged by-reference type.
+   For purposes of these rules, the determination of whether specifying a
+   representation aspect value for a type [could]{can} cause an object to have
+   some property is based solely on the properties of the type itself, not on
+   any available information about how the type is used. In particular, it
+   presumes that minimally aligned objects of this type [might]{can} be 
+   declared at some point.
 
-["need not support". No idea of a fix.]
+[Replace "could cause"; that is used sort of like a technical term, but it isn't
+a defined term. "might" also occurs here. This paragraph was left with the
+related other paragraphs so that the fix was consistent (there is no "need not"
+in this paragraph) - Editor.]
 
-33.2/2   * An implementation need not support Alignments specified for objects
-        of a by-reference type or for objects of types containing aliased
-        subcomponents if the specified Alignment is not a multiple of the
-        Alignment of the subtype of the object.
+Modify 13.2(8/4):
 
-[No attempt to fix.]
+  * For a packed record type, the components should be packed as tightly
+    as possible subject to the above alignment requirements, the Sizes of
+    the component subtypes, and any record_representation_clause that
+    applies to the type; the implementation [may, but need not,]{is allowed
+    to} reorder components or cross aligned word boundaries to improve the 
+    packing. A component whose Size is greater than the word size may be
+    allocated an integral number of words.
 
-51.2/2    * An implementation need not support a Size clause for a signed
-            integer type specifying a Size greater than that of the largest
-            signed integer type supported by the implementation in the absence
-            of a size clause (that is, when the size is chosen by default). A
-            corresponding limitation may be imposed for modular integer types,
-            fixed point types, enumeration types, record types, and array
-            types.
+Modify 13.3(29/2):
 
-[No attempt to fix.]
+  * An implementation {is not required to}[need not] support an Alignment 
+    clause for a signed integer type specifying an Alignment greater than 
+    the largest Alignment value that is ever chosen by default by the
+    implementation for any signed integer type. A corresponding limitation
+    may be imposed for modular integer types, fixed point types, enumeration
+    types, record types, and array types.
 
-51.3/2    * A nonconfirming size clause for the first subtype of a derived
-            untagged by-reference type need not be supported.
+Modify 13.3(30/2):
 
-[No attempt to fix.]
+  * An implementation {is not required to}[need not] support a nonconfirming 
+    Alignment clause which {can cause}[could enable] the creation of an object
+    of an elementary type which cannot be easily loaded and stored by
+    available machine instructions.
 
-65    * An implementation need not support specified Component_Sizes that are
-        less than the Size of the component subtype.
+[Replace "need not support", "could enable" - Editor.]
 
-[No attempt to fix.]
+Modify 13.3(30.1/2):
 
-13.4 Enumeration Representation Clauses
+  * An implementation {is not required to}[need not] support an Alignment
+    specified for a derived tagged type which is not a multiple of the
+    Alignment of the parent type. An implementation need not support a 
+    nonconfirming Alignment specified for a derived untagged by-reference
+    type.
 
-10    * An implementation should support at least the internal codes in the
-        range System.Min_Int .. System.Max_Int. An implementation need not
-        support enumeration_representation_clauses for boolean types.
+Modify 13.3(33.2/2):
 
-[No attempt to fix.]
+  * An implementation {is not required to}[need not] support Alignments
+    specified for objects of a by-reference type or for objects of types
+    containing aliased subcomponents if the specified Alignment is not a 
+    multiple of the Alignment of the subtype of the object.
 
-13.5.1 Record Representation Clauses
+Modify 13.3(51.2/2):
 
-22    * An implementation need not support a component_clause for a component
-        of an extension part if the storage place is not after the storage
-        places of all components of the parent type, whether or not those
-        storage places had been specified.
+  * An implementation {is not required to}[need not] support a Size clause for
+    a signed integer type specifying a Size greater than that of the largest
+    signed integer type supported by the implementation in the absence
+    of a size clause (that is, when the size is chosen by default). A
+    corresponding limitation may be imposed for modular integer types,
+    fixed point types, enumeration types, record types, and array types.
 
-[No attempt to fix.]
+Modify 13.3(51.3/2):
 
-13.11 Storage Management
+  * A nonconfirming size clause for the first subtype of a derived
+    untagged by-reference type {is not required to}[need not] be supported.
 
-25.4/2   * Otherwise, a default storage pool should be created at the point
-        where the anonymous access type is elaborated; such a storage pool
-        need not support deallocation of individual objects.
+Modify 13.3(65):
 
-[No attempt to fix.]
+  * An implementation {is not required to}[need not] support specified 
+    Component_Sizes that are less than the Size of the component subtype.
 
-13.12.1 Language-Defined Restrictions and Profiles
+Modify 13.4(10):
 
-7/2 The restriction_parameter_argument of a No_Dependence restriction shall be
-a name; the name shall have the form of a full expanded name of a library
-unit, but need not denote a unit present in the environment.
+ * An implementation should support at least the internal codes in the
+   range System.Min_Int .. System.Max_Int. An implementation {is not required
+   to}[need not] support enumeration_representation_clauses for boolean types.
 
-[No attempt to fix.]
+Modify 13.5.1(22):
 
-13.13.1 The Streams Subsystem
+ * An implementation {is not required to}[need not] support a component_clause
+   for a component of an extension part if the storage place is not after the
+   storage places of all components of the parent type, whether or not those
+   storage places had been specified.
 
-36/5 If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
-components of Stream_Element_Array need not be aliased.
+Modify 13.11(25.4/2):
 
-[No attempt to fix.]
+  * Otherwise, a default storage pool should be created at the point
+    where the anonymous access type is elaborated; such a storage pool
+    [need not support]{can have no mechanism for the} deallocation of
+    individual objects.
 
-A.4.12 Universal Text Buffers
+Modify 13.12.1(7/2):
 
-1/5 A universal text buffer can be used to save and retrieve text of any
-language-defined string type. The types used to save and retrieve the text
-need not be the same.
+    The restriction_parameter_argument of a No_Dependence restriction shall be
+    a name; the name shall have the form of a full expanded name of a library
+    unit, but [need not denote a]{can be a name that has no corresponding}
+    unit {currently} present in the environment.
 
-[No attempt to fix.]
+Modify 13.13.1(36/5):
 
-A.5.1 Elementary Functions
+    If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
+    components of Stream_Element_Array [need]{will} not be aliased.
 
-48  The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+[Tucker says: It really cannot be aliased if Stream_Element'Size is not a 
+multiple of Storage_Unit - Editor.]
 
-[No attempt to fix.]
+Modify A.4.12(1/5):
 
-A.10 Text Input-Output
+    A universal text buffer can be used to save and retrieve text of any
+    language-defined string type. The types used to save and retrieve the text
+    [need not be the same]{can be different}.
 
-8   The actual nature of terminators is not defined by the language and hence
-depends on the implementation. Although terminators are recognized or
-generated by certain of the procedures that follow, they are not necessarily
-implemented as characters or as sequences of characters. Whether they are
-characters (and if so which ones) in any particular implementation need not
-concern a user who neither explicitly outputs nor explicitly inputs control
-characters. The effect of input (Get) or output (Put) of control characters
-(other than horizontal tabulation) is not specified by the language.
+Modify A.5.1(48):
 
-[No attempt to fix.]
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined
+    type{, though that is not required}.
 
-A.10.8 Input-Output for Integer Types
+Modify A.10(8):
 
-23  The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+    The actual nature of terminators is not defined by the language and hence
+    depends on the implementation. Although terminators are recognized or
+    generated by certain of the procedures that follow, they are not
+    necessarily implemented as characters or as sequences of characters.
+    Whether they are characters (and if so which ones) in any particular
+    implementation [need]{is} not {of} concern {to} a user who neither 
+    explicitly outputs nor explicitly inputs control characters. The effect of
+    input (Get) or output (Put) of control characters (other than horizontal
+    tabulation) is not specified by the language.
 
-[No attempt to fix.]
+Modify A.10.8(23):
 
-A.10.9 Input-Output for Real Types
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined
+    type{, though that is not required}.
 
-36  The implementation of Put need not produce an output value with greater
-accuracy than is supported for the base subtype. The additional accuracy, if
-any, of the value produced by Put when the number of requested digits in the
-integer and fractional parts exceeds the required accuracy is implementation
-defined.
+Modify A.10.9(36):
 
-[No attempt to fix.]
+    The implementation of Put [need not]{may} produce an output value with
+    {no} greater accuracy than {that which} is supported for the base subtype.
+    The additional accuracy, if any, of the value produced by Put when the 
+    number of requested digits in the integer and fractional parts exceeds the
+    required accuracy is implementation defined.
 
-37  The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+Modify A.10.9(37):
 
-[No attempt to fix.]
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined
+    type{, though that is not required}.
 
-A.13 Exceptions in Input-Output
+Modify A.13(16):
 
-16  If the associated check is too complex, an implementation need not
-propagate Data_Error as part of a procedure Read (or the Read attribute) if
-the value read cannot be interpreted as a value of the required subtype.
+    {When}[If] the associated check is [too] complex, {it is optional to}[an
+    implementation need not] propagate Data_Error as part of a procedure Read
+    (or the Read attribute) {when}[if] the value read cannot be interpreted
+    is a value of the required subtype.]
 
-[No attempt to fix.]
+[Less radical alternative:
+    If the associated check is too complex, an implementation {does not have
+    to}[need not] propagate Data_Error as part of a procedure Read (or the
+    Read attribute) [if]{even though} the value read cannot be interpreted
+    as a value of the required subtype.
 
-B.1 Interfacing Aspects
+"does not have to" sounds rather close to a negative permission, as does most
+of the alternatives we tried. So the more substantial rewrite is
+preferred - Editor.]
 
-41/4 For each supported convention L other than Intrinsic, an implementation
-should support specifying the Import and Export aspects for objects of
-L-compatible types and for subprograms, and the Convention aspect for
-L-eligible types and for subprograms, presuming the other language has
-corresponding features. Specifying the Convention aspect need not be supported
-for scalar types, other than enumeration types whose internal codes fall
-within the range 0 .. 2**15-1.
+Modify B.1(41/4):
 
-[No attempt to fix.]
+    For each supported convention L other than Intrinsic, an implementation
+    should support specifying the Import and Export aspects for objects of
+    L-compatible types and for subprograms, and the Convention aspect for
+    L-eligible types and for subprograms, presuming the other language has
+    corresponding features. Specifying the Convention aspect [need
+    not]{should} be supported for [scalar types, other than] enumeration
+    types whose internal codes fall within the range 0 .. 2**15-1{, but no
+    recommendation is made for other scalar types}.
 
-B.3 Interfacing with C and C++
+Modify B.3(62.1/3):
 
-62.1/3 An implementation need not support specifying the Convention aspect
-with convention_identifier C in the following cases:
+    An implementation {is not required to}[need not] support specifying the
+    Convention aspect with convention_identifier C in the following cases:
 
-[No attempt to fix.]
+Modify C.3.2(24/5):
 
-C.3.2 The Package Interrupts
+    The implementation shall document, when the Ceiling_Locking policy (see
+    D.3) is in effect, the default ceiling priority assigned to a protected
+    object that contains a protected procedure that specifies either the
+    Attach_Handler or Interrupt_Handler aspects, but does not specify the
+    Interrupt_Priority aspect. This default [need not be the same]{can be
+    different} for [all]{different} interrupts.
 
-24/5 The implementation shall document, when the Ceiling_Locking policy (see
-D.3) is in effect, the default ceiling priority assigned to a protected object
-that contains a protected procedure that specifies either the Attach_Handler
-or Interrupt_Handler aspects, but does not specify the Interrupt_Priority
-aspect. This default need not be the same for all interrupts.
+Modify C.7.2(28):
 
-[No attempt to fix.]
+    An implementation [need not]{can avoid} actually [create]{creating} the
+    object corresponding to a task attribute until its value is set to
+    something other than that of Initial_Value, or until Reference is called
+    for the task attribute. Similarly, when the value of the attribute is
+    to be reinitialized to that of Initial_Value, the object may instead be
+    finalized and its storage reclaimed, to be recreated when needed later.
+    While the object does not exist, the function Value may simply return
+    Initial_Value, rather than implicitly creating the object.
 
-C.7.2 The Package Task_Attributes
+Modify D.2.2(17/2):
 
-28  An implementation need not actually create the object corresponding to a
-task attribute until its value is set to something other than that of
-Initial_Value, or until Reference is called for the task attribute. Similarly,
-when the value of the attribute is to be reinitialized to that of
-Initial_Value, the object may instead be finalized and its storage reclaimed,
-to be recreated when needed later. While the object does not exist, the
-function Value may simply return Initial_Value, rather than implicitly
-creating the object.
+    Implementations are allowed to define other task dispatching policies,
+    but {are not required to}[need not] support {specifying} more than one
+    task dispatching policy per partition.
 
-[No attempt to fix.]
+Modify D.2.2(18/2):
 
-D.2.2 Task Dispatching Pragmas
+    An implementation {is not required to}[need not] support pragma 
+    Priority_Specific_Dispatching if it is infeasible to support it in the
+    target environment.
 
-17/2 Implementations are allowed to define other task dispatching policies,
-but need not support more than one task dispatching policy per partition.
+Modify D.3(15/2):
 
-[No attempt to fix.]
+    Implementations are allowed to define other locking policies, but {are
+    not required to}[need not] support {specifying} more than one locking
+    policy per partition.
 
-18/2 An implementation need not support pragma Priority_Specific_Dispatching
-if it is infeasible to support it in the target environment.
+Modify D.4(15/2):
 
-[No attempt to fix.]
+    Implementations are allowed to define other queuing policies, but {are
+    not required to}[need not] support {specifying} more than one queuing 
+    policy per partition.
 
-D.3 Priority Ceiling Locking
+Modify D.4.1(8/5):
 
-15/2 Implementations are allowed to define other locking policies, but need
-not support more than one locking policy per partition.
+    Implementations are allowed to define other admission policies, but {are
+    not required to}[need not] support {specifying} more than one admission
+    policy per partition.
 
-[No attempt to fix.]
+Modify D.8(46):
 
-D.4 Entry Queuing Policies
+    Implementations targeted to machines with word size smaller than 32 bits
+    [need not support]{may omit support for} the full range and granularity of
+    the Time and Time_Span types.
 
-15/2 Implementations are allowed to define other queuing policies, but need
-not support more than one queuing policy per partition.
+[This and the ones like it below are Implementation Permissions, so they
+should be using some form of "may" - Editor.]
 
-[No attempt to fix.]
+Modify D.11(10):
 
-D.4.1 Admission Policies
+    An implementation [need not support]{may omit support for}
+    Asynchronous_Task_Control if it is infeasible to support it in the target
+    environment.
 
-8/5 Implementations are allowed to define other admission policies, but need
-not support more than one admission policy per partition.
+Modify D.14(28/2):
 
-[No attempt to fix.]
+    Implementations targeted to machines with word size smaller than 32 bits
+    [need not support]{may omit support for} the full range and granularity 
+    of the CPU_Time type.
 
-D.8 Monotonic Time
+Modify E.1(13):
 
-46  Implementations targeted to machines with word size smaller than 32 bits
-need not support the full range and granularity of the Time and Time_Span
-types.
+    In an implementation, the partitions of a distributed program
+    [need not]{may} be loaded and elaborated [all at the same time]{at
+    different times}; they may be loaded and elaborated one at a time over an 
+    extended period of time. An implementation may provide facilities to abort
+    and reload a partition during the execution of a distributed program.
 
-[No attempt to fix.]
+Modify E.2.3(20/5):
 
-D.11 Asynchronous Task Control
+    An implementation [need not support]{may omit support for} the 
+    Remote_Call_Interface aspect [nor]{or} the All_Calls_Remote aspect.
+    Explicit message-based communication between active partitions can be
+    supported as an alternative to RPC.
 
-10  An implementation need not support Asynchronous_Task_Control if it is
-infeasible to support it in the target environment.
+Modify E.5(27):
 
-[No attempt to fix.]
+    A body for the package System.RPC {is not required to}[need not] be 
+    supplied by the implementation.
 
-D.14 Execution Time
+Modify G.1.1(54):
 
-28/2 Implementations targeted to machines with word size smaller than 32 bits
-need not support the full range and granularity of the CPU_Time type.
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined 
+    type{, though that is not required}.
 
-[No attempt to fix.]
+Modify G.1.2(46):
 
-E.1 Partitions
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package with the appropriate predefined
+    nongeneric equivalent of Numerics.Generic_Complex_Types{, though that
+    is not required}; if they are, then the latter shall have been obtained
+    by actual instantiation of Numerics.Generic_Complex_Types.
 
-13  In an implementation, the partitions of a distributed program need not be
-loaded and elaborated all at the same time; they may be loaded and elaborated
-one at a time over an extended period of time. An implementation may provide
-facilities to abort and reload a partition during the execution of a
-distributed program.
+Modify G.2(3):
 
-[No attempt to fix.]
+    The two modes [need not actually be different]{can be one and the same}.
 
-E.2.3 Remote Call Interface Library Units
+Modify G.3.1(87/2): 
 
-20/5 An implementation need not support the Remote_Call_Interface aspect nor
-the All_Calls_Remote aspect. Explicit message-based communication between
-active partitions can be supported as an alternative to RPC.
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined 
+    type{, though that is not required}.
 
-[No attempt to fix.]
+Modify G.3.1(156/2):
 
-E.5 Partition Communication Subsystem
+    The nongeneric equivalent packages [may, but need not,]{can} be actual
+    instantiations of the generic package for the appropriate predefined 
+    type{, though that is not required}.
 
-27  A body for the package System.RPC need not be supplied by the
-implementation.
+Modify G.3.1(157/2): 
 
-[No attempt to fix.]
+    Although many operations are defined in terms of operations from
+    numerics.generic_complex_types, they [need not]{can} be implemented by
+    [calling those operations provided that the]{other operations that have
+    the same} effect[ is the same].
 
-G.1.1 Complex Types
+Modify H.7.1(14/5):
 
-54  The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+    The dispatching operation set is identified by a set of
+    dispatching_operation_specifiers. It indicates that the Nonblocking and
+    global effects of dispatching calls that match one of the specifiers{, 
+    rather than being} [need not be] accounted for by the Nonblocking or global
+    aspect, [but] are instead to be accounted for by the invoker of the
+    operation. A dispatching call matches a dispatching_operation_specifier if
+    the name or prefix of the call statically denotes the same operation(s) as
+    that of the dispatching_operation_specifier, and at least one of the
+    objects controlling the call is denoted by, or designated by, a name that
+    statically names the same object as that denoted by the object_name of the
+    dispatching_operation_specifier.
 
-[No attempt to fix.]
+!discussion
 
-G.1.2 Complex Elementary Functions
+To summarize the ISO rules from the Directives part 2 (often referred to as the
+drafting standard):
 
-46  The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package with the appropriate predefined
-nongeneric equivalent of Numerics.Generic_Complex_Types; if they are, then the
-latter shall have been obtained by actual instantiation of
-Numerics.Generic_Complex_Types.
+Requirements use "shall" preferably, or phrases involving forms of "require",
+"has to", or "it is necessary". "Must" is not allowed (it can be
+used for external requirements, such as government laws, but that usually
+doesn't apply to us).
 
-[No attempt to fix.]
+Recommendations use "should" preferably, or phrases involving forms of
+"recommend" or "ought to".
 
-G.2 Numeric Performance Requirements
+Permissions should use "may" preferably, or phrases using forms of "permit" or
+"allow". "Might" is not allowed in this context. Negative forms are not
+allowed (no "may not"); permissions must be positive. A quote: "Rather than
+using negative permissions, either rewrite the sentence to state what is
+permitted, or rewrite as a requirement/recommendation not to do something."
 
-3   The two modes need not actually be different.
+Possibility should use "can", or phrases using forms of "able" or "possible".
 
-[No attempt to fix.]
+ISO has taken this further and does not want to see "might", "could", or
+"need" at all; they assume that they are being used in one of the above
+contexts. I don't know where "need" comes from (other than the "House Style",
+but that's not normative), the Directives never mentions it as a word
+to avoid, and in fact it uses the word "needs" with the meaning of desires
+repeatedly. But the Directives is clear that one should not use any
+words other than the above to express requirements, recommendations, or
+permissions.
 
-G.3.1 Real Vectors and Matrices
+Note that while some phrases are given meanings, other uses of the words seem
+be to be allowed by the Directives. For instance, "necessary" is used in many
+contexts in the Directives that are not requirements.
 
-87/2 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+We have a particular problem with "need not", used frequently to get around
+not being able to say "may not". But negative permissions aren't allowed at
+all, in any verbal form. (They have to be reworded positively, or integrated
+into the requirements if that's not possible.) This is a problem since many
+of our permissions are exceptions to rules stated elsewhere, and those have
+to be written negatively. We handle just this problem in this AI; other
+wording changes needed are handled in AI12-0438-1, AI12-0439-1, and AI12-0445-1.
 
-[No attempt to fix.]
+--
 
-156/2 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+We could consider making wording changes only for the ISO version (new
+commands would be needed in the formatter to support that if is done a lot
+ - currently, we can only do that on a full paragraph basis or with a few 
+macros - but new commands should not be hard to define and implement).
 
-[No attempt to fix.]
+However, that would add complications to future maintenance (as we would need
+to somehow have both versions in any Corrigendum document, one for our use and
+one for the actual ISO Corrigendum). As such, we want to make any changes that
+do not clearly alter the meaning or harm the understandability of the text.
 
-157/2 Although many operations are defined in terms of operations from
-numerics.generic_complex_types, they need not be implemented by calling those
-operations provided that the effect is the same.
+!ASIS
 
-[No attempt to fix.]
+No ASIS effect.
 
-H.7.1 The Use_Formal and Dispatching Aspects
+!ACATS test
 
-14/5 The dispatching operation set is identified by a set of
-dispatching_operation_specifiers. It indicates that the Nonblocking and global
-effects of dispatching calls that match one of the specifiers need not be
-accounted for by the Nonblocking or global aspect, but are instead to be
-accounted for by the invoker of the operation. A dispatching call matches a
-dispatching_operation_specifier if the name or prefix of the call statically
-denotes the same operation(s) as that of the dispatching_operation_specifier,
-and at least one of the objects controlling the call is denoted by, or
-designated by, a name that statically names the same object as that denoted by
-the object_name of the dispatching_operation_specifier.
+No ACATS test should be needed, no change in meaning is intended and these
+are notes anyway.
 
-[No attempt to fix.]
+!appendix
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent