CVS difference for arm/source/07.mss
--- arm/source/07.mss 2000/04/15 00:44:01 1.2
+++ arm/source/07.mss 2000/04/15 21:58:26 1.3
@@ -1,13 +1,13 @@
@Part(07, Root="ada.mss")
-@SetPageHeadings{$Date: 2000/04/15 00:44:01 $}
+@SetPageHeadings{$Date: 2000/04/15 21:58:26 $}
@LabeledChapter{Packages}
@Comment{$Source: e:\\cvsroot/ARM/Source/07.mss,v $}
-@Comment{$Revision: 1.2 $}
+@Comment{$Revision: 1.3 $}
@begin{Intro}
-@begin{Redundant}
+@redundant[
@ToGlossaryAlso{Term=<Package>,
Text=<Packages are program units that allow the specification of groups of
logically related entities.
@@ -20,18 +20,18 @@
@IndexSee{Term=[encapsulation],See=(package)}
@IndexSee{Term=[module],See=(package)}
@IndexSeeAlso{Term=[class],See=(package)}
-@end{Redundant}
+]
@end{Intro}
@LabeledSection{Package Specifications and Declarations}
@begin{Intro}
-@begin{Redundant}
+@redundant[
A package is generally provided in two parts: a
@nt{package_specification} and a @nt{package_body}.
Every package has a @nt{package_specification}, but not all packages
have a @nt{package_body}.
-@end{Redundant}
+]
@end{Intro}
@begin{Syntax}
@@ -93,7 +93,7 @@
@SeeSecNum(Compilation Units - Library Units).
@end{Ramification}
-@begin{Redundant}
+@redundant[
An entity declared in the private part of a package is visible
only within the declarative region of the package itself
(including any child units @em
@@ -103,7 +103,7 @@
package; furthermore, direct visibility of such entities can be
achieved by means of @nt{use_clause}s
(@lSeeSecNum{Selected Components} and @RefSecNum{Use Clauses}).
-@end{Redundant}
+]
@end{StaticSem}
@begin{RunTime}
@@ -189,7 +189,7 @@
@LabeledSection{Package Bodies}
@begin{Intro}
-@begin{Redundant}
+@redundant[
In contrast to the entities declared in the visible part of a
package, the entities declared in the @nt{package_body} are
visible only
@@ -199,7 +199,7 @@
a group of related subprograms in
which the logical operations available to clients are clearly
isolated from the internal entities.
-@end{Redundant}
+]
@end{Intro}
@begin{Syntax}
@@ -228,8 +228,7 @@
@key<pragma> Elaborate_Body can be used to require
a @nt<library_unit_declaration> to have a body
(@lSeeSecNum{Elaboration Control})
-if it would not otherwise @oChg{}require@oEndChg{} one].
-@oChgRef{94-4409.a}
+if it would not otherwise require one].
@begin{Ramification}
The first part of the rule forbids a @nt{package_body} from
standing alone @em it has to belong to some previous
@@ -362,7 +361,7 @@
@LabeledSection{Private Types and Private Extensions}
@begin{Intro}
-@begin{Redundant}
+@redundant[
The declaration (in the visible part of a
package) of a type as a private type or private extension
serves to separate the characteristics that can be used
@@ -375,7 +374,7 @@
@IndexSee{Term=[opaque type],See=(private types and private extensions)}
@IndexSee{Term=[abstract data type (ADT)],See=(private types and private extensions)}
@IndexSee{Term=[ADT (abstract data type)],See=(private types and private extensions)}
-@end{Redundant}
+]
@end{Intro}
@begin{MetaRules}
@@ -424,7 +423,7 @@
full view.
@end{Reason}
-@Chg{}
+
@Redundant[A type shall be completely defined before it is frozen
(@lSeeSecNum{Completions of Declarations} and
@RefSecNum{Freezing Rules}).
@@ -439,26 +438,20 @@
This rule is stated officially in
@RefSec{Completions of Declarations}.
@end{TheProof}
-@EndChg{}
-@begin{ChgNote}
- Rule moved here from @RefSec{Freezing Rules},
- as per WG9 resolution.
-@end{ChgNote}
+
+
@Redundant[A private type is limited if its declaration includes
the reserved word @key[limited];
a private extension is limited if its ancestor type is limited.]
If the partial view is nonlimited, then
the full view shall be nonlimited.
-@oBigChg{}
+
If a tagged partial view is limited,
then the full view shall be limited.
@Redundant[On the other hand,
-if an untagged partial view@oEndBigChg{} is limited,
+if an untagged partial view is limited,
the full view may be limited or nonlimited.]
-@oChgRef{94-4662.a}
-@oChgRef{94-4665.a}
-@oChgRef{94-4828.b}
If the partial view is tagged,
then the full view shall be tagged.
@@ -473,11 +466,10 @@
Note that deriving from a partial view within its immediate scope
can only occur in a package that is a child of the one where the partial
view is declared.
-The rule implies that in @oChg{}the visible part of a public child package,
+The rule implies that in the visible part of a public child package,
it is impossible to derive from an untagged private type declared in the
-visible part of the parent package in the case where@oEndChg{} the full
+visible part of the parent package in the case where the full
view of the parent type turns out to be tagged.
-@oChgRef{94-4443.a}
We considered a model in which the derived type was implicitly
redeclared at the earliest place within its immediate scope where
characteristics needed to be added.
@@ -559,7 +551,7 @@
corresponding record extension if the parent is nonlimited.
@end{Reason}
@begin{Ramification}
-@Chg{}
+
A type derived from an untagged private type is untagged,
even if the full view of the parent is tagged,
and even at places that can see the parent:
@@ -592,10 +584,7 @@
The component name X is never visible for this view,
although the component is still there @em one
can get one's hands on it via a @nt{type_conversion}.
-@EndChg{}
-@oChgRef{94-4941.a}
-@oChgRef{94-4946.a}
-@ChgRef{94-5001.g}
+
@end{Ramification}
@Defn2{Term=[ancestor subtype], Sec=(of a @nt<private_extension_declaration>)}
@@ -614,8 +603,8 @@
possibly from a series of types produced by
@nt{generic_instantiation}s.
@end{Reason}
+
-@oBigChg{}
If the declaration of a partial view includes
a @nt{known_discriminant_part}, then
the @nt{full_type_declaration} shall have a fully conforming
@@ -630,12 +619,11 @@
If the ancestor subtype has discriminants,
then it is usually best to make it unconstrained.
@end{Discussion}
-@oEndBigChg{}
+
@begin{Ramification}
If the partial view has a @nt<known_discriminant_part>,
- then the full view has to be a composite, @oChg{}non-array@oEndChg{} type,
+ then the full view has to be a composite, non-array type,
since only such types may have known discriminants.
-@oChgRef{94-4493.c}
Also, the full view cannot inherit the discriminants in this case;
the @nt{known_discriminant_part} has to be explicit.
@@ -655,8 +643,8 @@
the private type declaration has to have an
@nt{unknown_discriminant_part}.
@end{Ramification}
+
-@oBigChg{}
If a private extension inherits known discriminants from the ancestor
subtype,
then the full view shall also inherit its discriminants from the
@@ -676,17 +664,13 @@
then the @nt{full_type_declaration} may define
a definite or an indefinite subtype,
with or without discriminants.]
-@oEndBigChg{}
-@oChgRef{94-4474.a}
-@oChgRef{94-4886.a}
+
+
-@oBigChg{}
If a partial view has neither known nor unknown discriminants,
then the @nt{full_type_declaration} shall define a definite subtype.
-@oEndBigChg{}
-@oChgRef{94-4886.a}
-@oChgRef{94-4947.a}
+
If the ancestor subtype of a private extension has constrained
discriminants,
then the parent subtype of the full view shall impose a statically
@@ -695,7 +679,7 @@
@begin{Ramification}
If the parent type of the full view is not the ancestor type,
but is rather some descendant thereof, the constraint on
- the discriminants of the @oChg{}parent@oEndChg{} type might come from
+ the discriminants of the parent type might come from
the declaration of some intermediate type in the derivation
chain between the ancestor type and the parent type.
@end{Ramification}
@@ -711,8 +695,8 @@
@end{Example}
The constraints in this example do not statically match.
+
-@oBigChg{}
If the constraint on the parent subtype of the full view depends on
discriminants of the full view, then the ancestor subtype has to be
unconstrained:
@@ -733,7 +717,7 @@
``is new One_Discrim(A => C);'',
because then the constraints would not statically match.
(Constraints that depend on discriminants are not static.)
-@oEndBigChg{}
+
@end{Reason}
@end{Legality}
@@ -797,11 +781,11 @@
@PDefn2{Term=[elaboration], Sec=(private_extension_declaration)}
The elaboration of a @nt{private_extension_declaration} elaborates
the @i(ancestor_)@nt<subtype_indication>, and creates a
-partial view of a type.@Chg{}
+partial view of a type.
@end{RunTime}
@begin{NotesNotes}
-@EndChg{}The partial view of a type as declared by a @nt<private_type_declaration>
+The partial view of a type as declared by a @nt<private_type_declaration>
is defined to be a composite view (in @RefSecNum{Types and Subtypes}).
The full view of the type might or might not be composite.
A private extension is also composite,
@@ -982,12 +966,10 @@
where the corresponding declaration from the parent is
visible.
If there is no such place, then the inherited subprogram
-is not declared @oChg{}at all.
-@Redundant[An inherited subprogram that is not declared at all@oEndChg{}
+is not declared at all.
+@Redundant[An inherited subprogram that is not declared at all
cannot be named in a call and cannot be overridden,
but for a tagged type, it is possible to dispatch to it.]
-@oChgRef{94-4678.a}
-@oChgRef{94-4683.a}
For a @nt{private_extension_declaration},
each inherited subprogram is declared immediately after
@@ -1080,7 +1062,7 @@
this would override the one inherited from Root.
This is different from the situation with T2.
-@oChg{}
+
T5 inherits Op1 and two Op2's from T2.
Op1 is implicitly declared immediately after the declaration of T5,
as is the Op2 that came from Unrelated.Op2.
@@ -1088,17 +1070,14 @@
implicitly declared for T5,
since T2's version of that Op2 is never visible (anywhere @em it never
got declared either).
-@oEndChg{}
-@oChgRef{94-4677.a}
-@oChgRef{94-4682.a}
-@oChgRef{94-4439.a}
+
For all of these rules, implicit private parts and bodies are assumed as
needed.
It is possible for characteristics of a type to be revealed in more than
one place:
-@oChg{}
+
@begin{Example}
@key[package] P @key[is]
@key[type] Comp1 @key[is] @key[private];
@@ -1130,8 +1109,7 @@
@key[end] R;
@key[end] P.Q;
@end{Example}
-@oEndChg{}
-@oChgRef{94-4444.a}
+
@end{Discussion}
@Redundant[The Class attribute is defined for tagged subtypes in
@@ -1256,13 +1234,13 @@
@LabeledSection{Deferred Constants}
@begin{Intro}
-@begin{Redundant}
+@redundant[
Deferred constant declarations may be used to declare constants
in the visible part of a package,
but with the value of the constant given in the private part.
They may also be used to declare constants imported from other
languages (@lSeeSecNum{Interface to Other Languages}).
-@end{Redundant}
+]
@end{Intro}
@begin{Legality}
@@ -1323,15 +1301,12 @@
the visible part of a @nt{package_specification},
and has no full constant declaration.]
-@Chg{}
+
The completion of a deferred constant declaration shall occur
before the constant is frozen
(@lSeeSecNum{Deferred Constants}).
-@EndChg{}
-@begin{ChgNote}
- Rule moved here from @RefSec{Freezing Rules},
- as per WG9 resolution.
-@end{ChgNote}
+
+
@end{Legality}
@begin{RunTime}
@@ -1346,7 +1321,7 @@
private type or private extension is not allowed before the corresponding
@nt{full_type_declaration}. This is a consequence of the freezing
rules for types
-@Chg{}(@lSeeSecNum{Freezing Rules}).@EndChg{}
+(@lSeeSecNum{Freezing Rules}).
@begin{Ramification}
Multiple or single declarations are allowed for the
deferred and the full declarations, provided that the
@@ -1430,13 +1405,13 @@
@LabeledSection{Limited Types}
@begin{Intro}
-@begin{Redundant}
+@redundant[
@ToGlossaryAlso{Term=<Limited type>,
Text=<A limited type is (a view of) a type for which
the assignment operation is not allowed.
A nonlimited type is a (view of a) type for which the assignment
operation is allowed.>}
-@end{Redundant}
+]
@begin{Discussion}
The concept of the @i(value) of a limited type is difficult
to define, since the abstract value of a limited type often
@@ -1638,7 +1613,7 @@
@LabeledSection{User-Defined Assignment and Finalization}
@begin{Intro}
-@begin{Redundant}
+@redundant[
@Defn{user-defined assignment}
@Defn2{Term=[assignment], Sec=(user-defined)}
Three kinds of actions are
@@ -1677,7 +1652,7 @@
components of a controlled object, and an Adjust
procedure which is invoked as the last step of an assignment to
a (nonlimited) controlled object.
-@end{Redundant}
+]
@begin{Ramification}
Here's the basic idea of initialization, value adjustment, and finalization,
whether or not user defined:
@@ -1705,7 +1680,7 @@
@tabclear()
@ChildUnit{Parent=[Ada],Child=[Finalization],Expanded=[Ada.Finalization]}
@key[package] Ada.Finalization @key[is]
- @oBigChg{}@key[pragma] Preelaborate(Finalization);@oChgRef{94-4528.a}@oEndBigChg{}
+ @key[pragma] Preelaborate(Finalization);
@LangDefType{Package=[Ada.Finalization],Type=[Controlled]}
@key[type] Controlled @key[is abstract tagged private];
@@ -1733,15 +1708,13 @@
@end{Discussion}
The (default) implementations of
Initialize, Adjust, and Finalize have no effect.
-@oChg{}
+
The predefined "=" operator of type Controlled always returns True,
@Redundant[since this operator is incorporated into
the implementation of the predefined equality operator of types derived
from Controlled, as explained in
@RefSecNum(Relational Operators and Membership Tests).]
-@oEndChg{}
-@oChgRef{94-4619.a}
-@oChgRef{94-4843.a}
+
The type Limited_Controlled is like Controlled, except
that it is limited and it lacks the primitive subprogram Adjust.
@begin{Reason}
@@ -1960,9 +1933,8 @@
@end{TheProof}
@begin{Itemize}
For an @nt{assignment_statement} that assigns to an object the value
-@oBigChg{}of that same object,@oEndBigChg{}
+of that same object,
the implementation need not do anything.
-@oChgRef{94-4495.a}
@begin{Ramification}
In other words, even if an object is controlled and a combination
of Finalize and Adjust on the object might have a net
@@ -2028,19 +2000,18 @@
@LabeledSubSection{Completion and Finalization}
@begin{Intro}
-@begin{Redundant}
+@redundant[
This subclause defines @i{completion} and @i{leaving} of the execution
of constructs and entities.
-A @i{master} is @oBigChg{}the execution of a construct that@oEndBigChg{}
+A @i{master} is the execution of a construct that
includes finalization of local objects after it is complete
(and after waiting for any local tasks
@em @lSeeSecNum(Task Dependence - Termination of Tasks)),
but before leaving.
-@oChgRef{94-4715.a}
Other constructs and entities are left immediately upon completion.
@IndexSee{Term=[cleanup],See=(finalization)}
@IndexSee{Term=[destructor],See=(finalization)}
-@end{Redundant}
+]
@end{Intro}
@begin{RunTime}
@@ -2080,20 +2051,12 @@
@Defn{master}
Leaving an execution happens immediately after its completion,
except in the case of a @i{master}:
-@oBigChg{}the execution of
+the execution of
a @nt{task_body}, a @nt{block_statement},
a @nt{subprogram_body}, an @nt{entry_body}, or an @nt{accept_statement}.
-A master@oEndBigChg{} is finalized after it is
+A master is finalized after it is
complete, and before it is left.
-@oChgRef{94-4715.a}
-@begin{oBigChgNote}
- A master is now officially defined to be the @i{execution of} a
- @nt{subprogram_body}, etc,
- instead of being the @nt{subprogram_body} (or whatever) itself.
- This simplifies some of the rules, such as the accessibility rules.
- We still allow ourselves some sloppiness when the meaning is clear
- from context; we have always used the term in both senses.
-@end{oBigChgNote}
+
@begin{Reason}
Note that although an @nt{accept_statement} has no
@nt{declarative_part}, it can call functions and evaluate
@@ -2104,19 +2067,18 @@
@end{Reason}
@Defn2{Term=[finalization], Sec=(of a master)}
-@oBigChg{}
+
For the @i{finalization} of a master,
dependent tasks are first awaited,
as explained in @RefSecNum{Task Dependence - Termination of Tasks}.
Then each object whose accessibility level is
the same as that of the master is finalized
if the object was successfully initialized and still exists.
-@oEndBigChg{}
-@oChgRef{94-4715.a}
+
@Redundant[These actions are performed whether the master is left
by reaching the last statement or via a transfer of control.]
@begin{Ramification}
-@oBigChg{}
+
As explained in @RefSecNum{Operations of Access Types},
the set of objects with the same accessibility level
as that of the master
@@ -2134,8 +2096,7 @@
Thus, after leaving a master, the only objects yet to be
finalized are those whose accessibility level is less deep than that
of the master.
-@oEndBigChg{}
-@oChgRef{94-4715.a}
+
@end{Ramification}
@begin{Honest}
Subcomponents of objects due to be finalized are not finalized
@@ -2149,7 +2110,7 @@
But if the containing object is finalized, we don't want to require
repeated finalization of the subcomponents,
as might normally be implied by the recursion in finalization of a
-master and the recursion in finalization of an object.@oChg{}@oEndChg{}
+master and the recursion in finalization of an object.
@end{Reason}
When a transfer of control causes completion of an execution, each
included master is finalized in order, from
Questions? Ask the ACAA Technical Agent