Version 1.1 of ai12s/ai12-0444-1.txt
!standard 1.1.5(8) 22-04-27 AI12-0444-1/01
!standard 3.5.4(26)
!standard 3.5.6(7/5)
!standard 3.5.6(8/5)
!standard 9.5.3(25)
!standard xx.xx(xx)
!standard xx.xx(xx)
!standard xx.xx(xx)
!standard xx.xx(xx)
!class presentation 22-04-27
!status work item 22-04-27
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings to remove "need not"
!summary
Several paragraphs needed to be reworded to avoid using "need not".
!question
ISO comment #20 says:
Verbal forms used to express provisions in the text do not always comply
with the rules specified in the ISO/IEC Directives, Part 2. Do not use
verbal forms ("could", "might", "need") that are not defined in the
ISO/IEC Directives, Part 2.
Should we fix any uses of "need not"? (Yes.)
!recommendation
Reword all wording including "need not", perferably 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.
!wording
Modify 1.1.5(8):
The language rules define certain kinds of errors that {are not
expected to}[need not] be detected either prior to or during run time,
but if not detected, the range of possible effects shall be bounded.
The errors of this category are called bounded errors. The possible
effects of a given bounded error are specified for each such error,
but in any case one possible effect of a bounded error is the raising
of the exception Program_Error.
Modify 3.5.4(24):
For the execution of a predefined operation of a signed integer type, {it
is optional to}[the implementation need not] raise Constraint_Error if the
result is outside the base range of the type, so long as the correct result
is produced.
["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
part to make this sensible - Editor.]
Alternatively:
for the execution of a predefined operation of a signed integer type,
{raising}[the implementation need not raise] Constraint_Error {is
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(26):
An implementation may provide nonstandard integer types, descendants of
root_integer that are declared outside of the specification of package
Standard, which {may have different}[need not have all the standard]
characteristics {than}[of] a type defined by an integer_type_definition.
For example, a nonstandard integer type
{can}[might] have an asymmetric base range or it {can be disallowed}[might
not be allowed] as an array or loop index (a very long integer). Any type
descended from a nonstandard
integer type is also nonstandard. An implementation may place arbitrary
restrictions on the use of such types; it is implementation defined whether
operators that are predefined for "any integer type" are defined for a
particular nonstandard integer type. In any case, such types are not permitted
as explicit_generic_actual_parameters for formal scalar types - see 12.5.2.
["Could" would be better, especially for the second case, but that also a word
that's not allowed. Negative permissions are not allowed at all, there is no
negative form of "may". Thus the rewording for "need not" and "might not".
- Editor.]
Modify 3.5.6(7/5):
For the execution of a predefined operation of a real type, {it is
optional to}[the implementation need not] raise Constraint_Error if the
result is outside the base range of the type, so long as the correct
result is produced, or the Machine_Overflows attribute of the type is
False (see G.2.1).
["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
part to make this sensible - Editor.]
An alternative update would be:
For the execution of a predefined operation of a real type, {raising}
[the implementation need not raise] Constraint_Error {is required} if the
result is outside the base range of the type, {unless}[so long as] the
correct result is produced, or the Machine_Overflows attribute of the type
is False (see G.2.1).
Modify 3.5.6(8/5):
An implementation may provide nonstandard real types, descendants of
root_real that are declared outside of the specification of package Standard,
which {may have different}[need not have all the standard]
characteristics {than}[of] a type defined by a
real_type_definition. For example, a nonstandard real type {can}[might] have an
asymmetric or unsigned base range, or its predefined operations {can}[might]
wrap around or "saturate" rather than overflow (modular or saturating arithmetic),
or it {can have a different}[might not conform to the] accuracy model {than is
standard }(see G.2.1). Any type descended
from a nonstandard real type is also nonstandard. An implementation may place
arbitrary restrictions on the use of such types; it is implementation defined
whether operators that are predefined for "any real type" are defined for a
particular nonstandard real type. In any case, such types are not permitted as
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.]
3.5.7 Floating Point Types
5 Each simple_expression of a real_range_specification is expected to be of
any real type; the types need not be the same.
[No attempt to fix.]
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
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.
[No attempt to fix.]
10.2.1 Elaboration Control
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.
[No attempt to fix.]
11.4.2 Pragmas Assert and Assertion_Policy
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.
[Multiple "need not allow"; two bonus "could"s too. No idea of a fix.]
[No attempt to fix.]
11.6 Exceptions and Optimization
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.
[No attempt to fix. Fix "need be", too.]
12.5.1 Formal Private and Derived Types
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.
[No attempt to fix. "(but discriminants are not required)"??]
13.1 Operational and Representation Aspects
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.
["need not support". No idea of a fix.]
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.
["need not support". No idea of a fix.]
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.
["need not support", "could cause". No idea of a fix.]
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.
["need not support", "could cause". No idea of a fix.]
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.
["need not support", "could cause". No idea of a fix.]
27/3 * An implementation need not support specifying a nonconfirming
subtype-specific representation aspect value for an indefinite or
abstract subtype.
["need not support". No idea of a fix.]
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.
["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.]
13.2 Packed Types
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.
[No attempt to fix.]
13.3 Operational and Representation Attributes
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.
["need not support". No idea of a fix.]
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.
["need not support", "could enable". No idea of a fix.]
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.
["need not support". No idea of a fix.]
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.
[No attempt to fix.]
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.
[No attempt to fix.]
51.3/2 * A nonconfirming size clause for the first subtype of a derived
untagged by-reference type need not be supported.
[No attempt to fix.]
65 * An implementation need not support specified Component_Sizes that are
less than the Size of the component subtype.
[No attempt to fix.]
13.4 Enumeration Representation Clauses
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.
[No attempt to fix.]
13.5.1 Record Representation Clauses
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.
[No attempt to fix.]
13.11 Storage Management
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.
[No attempt to fix.]
13.12.1 Language-Defined Restrictions and Profiles
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.
[No attempt to fix.]
13.13.1 The Streams Subsystem
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.
[No attempt to fix.]
A.4.12 Universal Text Buffers
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.
[No attempt to fix.]
A.5.1 Elementary Functions
48 The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
[No attempt to fix.]
A.10 Text Input-Output
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.
[No attempt to fix.]
A.10.8 Input-Output for Integer Types
23 The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
[No attempt to fix.]
A.10.9 Input-Output for Real Types
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.
[No attempt to fix.]
37 The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
[No attempt to fix.]
A.13 Exceptions in Input-Output
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.
[No attempt to fix.]
B.1 Interfacing Aspects
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.
[No attempt to fix.]
B.3 Interfacing with C and C++
62.1/3 An implementation need not support specifying the Convention aspect
with convention_identifier C in the following cases:
[No attempt to fix.]
C.3.2 The Package 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.
[No attempt to fix.]
C.7.2 The Package Task_Attributes
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.
[No attempt to fix.]
D.2.2 Task Dispatching Pragmas
17/2 Implementations are allowed to define other task dispatching policies,
but need not support more than one task dispatching policy per partition.
[No attempt to fix.]
18/2 An implementation need not support pragma Priority_Specific_Dispatching
if it is infeasible to support it in the target environment.
[No attempt to fix.]
D.3 Priority Ceiling Locking
15/2 Implementations are allowed to define other locking policies, but need
not support more than one locking policy per partition.
[No attempt to fix.]
D.4 Entry Queuing Policies
15/2 Implementations are allowed to define other queuing policies, but need
not support more than one queuing policy per partition.
[No attempt to fix.]
D.4.1 Admission Policies
8/5 Implementations are allowed to define other admission policies, but need
not support more than one admission policy per partition.
[No attempt to fix.]
D.8 Monotonic Time
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.
[No attempt to fix.]
D.11 Asynchronous Task Control
10 An implementation need not support Asynchronous_Task_Control if it is
infeasible to support it in the target environment.
[No attempt to fix.]
D.14 Execution Time
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.
[No attempt to fix.]
E.1 Partitions
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.
[No attempt to fix.]
E.2.3 Remote Call Interface Library Units
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.
[No attempt to fix.]
E.5 Partition Communication Subsystem
27 A body for the package System.RPC need not be supplied by the
implementation.
[No attempt to fix.]
G.1.1 Complex Types
54 The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
[No attempt to fix.]
G.1.2 Complex Elementary Functions
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.
[No attempt to fix.]
G.2 Numeric Performance Requirements
3 The two modes need not actually be different.
[No attempt to fix.]
G.3.1 Real Vectors and Matrices
87/2 The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
[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.
[No attempt to fix.]
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.
[No attempt to fix.]
H.7.1 The Use_Formal and Dispatching Aspects
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 attempt to fix.]
****************************************************************
Questions? Ask the ACAA Technical Agent