CVS difference for ais/ai-00106.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00106.txt

--- ais/ai-00106.txt	2000/07/13 04:31:27	1.8
+++ ais/ai-00106.txt	2000/08/01 05:39:33	1.9
@@ -26,7 +26,7 @@
 that applies to a name that is an explicit_dereference.
 
 3. An implicit call, such as an implicit call to Initialize, freezes the
-called subprogram.  This is true even if the implicit call is removed
+called subprogram. This is true even if the implicit call is removed
 via the implementation permissions in 7.6(18-21).
 
 4. If a name or expression is implicitly converted to a type or subtype,
@@ -89,7 +89,7 @@
 ----------------
 
 3. Does an implicit call to Initialize freeze the subprogram? (Yes.) The
-freezing rules seem to apply to explicit constructs.  For example:
+freezing rules seem to apply to explicit constructs. For example:
 
     type T is new Controlled with record...;
     procedure Initialize(X: in out T);
@@ -104,7 +104,7 @@
 
 ----------------
 
-4. It seems unclear whether an implicit type conversion freezes.  For
+4. It seems unclear whether an implicit type conversion freezes. For
 example:
 
     type Color is (Red, Yellow);
@@ -116,7 +116,7 @@
     subtype S is T range 1..10; -- Freezes type T?  (Yes.)
 
 The expressions "1" and "10" are of type universal_integer, so T is not
-frozen.  But it seems like it should be -- the value is implicitly
+frozen. But it seems like it should be -- the value is implicitly
 converted to type T, and so it's very much like an expression of type T.
 
 13.14(12) seems to agree that the implicit conversion should freeze.
@@ -139,7 +139,7 @@
 
 1. Add object names to 13.14(8):
 
-   A static expression causes freezing where it occurs.  [A] {An object
+   A static expression causes freezing where it occurs. [A] {An object
    name or} nonstatic expression causes freezing where it occurs, unless
    the {name or} expression is part of a default_expression, a
    default_name, or a per-object expression of a component's constraint,
@@ -158,7 +158,7 @@
 
    An implicit call to one of the subprograms in Ada.Finalization
    or System.Storage_Pools freezes the same entities that would
-   be frozen by an explicit call.  This is true even if the implicit
+   be frozen by an explicit call. This is true even if the implicit
    call is removed via the Implementation Permissions in 7.6.
 
 4. Add a paragraph to cover implicit type conversions:
@@ -169,23 +169,23 @@
 
 !discussion
 
-1. 13.14(8) says that expressions cause freezing.  It does not cover
+1. 13.14(8) says that expressions cause freezing. It does not cover
 names that denote objects, but it should -- the reasons for the
 existence of 13.14(8) apply equally to object names.
 
 Given the conclusion herein reached, the above example (1) is illegal.
 The occurrence of "X.all" freezes the type T, but the type is not
-completely defined at that point, thus violating 13.14(17).  Note that
+completely defined at that point, thus violating 13.14(17). Note that
 the declaration of Y is an object_renaming_declaration, not an
 object_declaration, so 13.14(6) does not apply.
 
 If the above example (1) were legal, it would necessarily raise
 Constraint_Error due to dereferencing a null access value.
 However, AARM 13.14(1.o-1.u) explains that we do not wish to rely on
-run-time checks for this kind of example.  Furthermore, it is possible
+run-time checks for this kind of example. Furthermore, it is possible
 to construct examples that do not necessarily raise an exception.
 
-Object_renaming_declarations are not the only offender.  Here's another
+Object_renaming_declarations are not the only offender. Here's another
 example:
 
     with System.Storage_Pools; use System.Storage_Pools;
@@ -211,9 +211,9 @@
 
 2. Clearly, the same rules should apply to explicit and
 implicit dereferences -- in the example, "Obj.all.D" and "Obj.D" should
-freeze the same entities.  Therefore, a new bullet after 13.14(11) is added
+freeze the same entities. Therefore, a new bullet after 13.14(11) is added
 to cover implicit_dereferences, so that the "Obj" in "Obj.D" freezes the same
-entities that "Obj.all" would freeze.  That is, an implicit_dereference
+entities that "Obj.all" would freeze. That is, an implicit_dereference
 freezes the denoted object and its nominal subtype.
 
 Since an implicit_dereference is not an expression and is not a name
@@ -222,7 +222,7 @@
 ----------------
 
 3 and 4. Clearly implicit calls and implicit conversions should freeze
-in the same manner as their explicit counterparts.  An implicit call
+in the same manner as their explicit counterparts. An implicit call
 should freeze even if it is removed via the implementation permissions
 in 7.6(18-21); otherwise, there would be a portability problem.
 
@@ -230,12 +230,12 @@
 
 @drepl
 A construct that (explicitly or implicitly) references an entity can
-cause the freezing of the entity, as defined by subsequent paragraphs. At
+cause the @i<freezing> of the entity, as defined by subsequent paragraphs. At
 the place where a construct causes freezing, each @fa<name>, expression,
 or @fa<range> within the construct causes freezing:
 @dby
 A construct that (explicitly or implicitly) references an entity can
-cause the freezing of the entity, as defined by subsequent paragraphs. At
+cause the @i<freezing> of the entity, as defined by subsequent paragraphs. At
 the place where a construct causes freezing, each @fa<name>, @fa<expression>,
 @fa<implicit_dereference>, or @fa<range> within the construct causes freezing:
 
@@ -248,7 +248,7 @@
 component's @fa<constraint>, in which case, the freezing occurs later as part of
 another construct.
 @dby
-A static expression causes freezing where it occurs.  An object
+A static expression causes freezing where it occurs. An object
 name or nonstatic expression causes freezing where it occurs, unless
 the name or expression is part of a @fa<default_expression>, a
 @fa<default_name>, or a per-object expression of a component's @fa<constraint>,

Questions? Ask the ACAA Technical Agent