CVS difference for ais/ai-00106.txt

--- ais/ai-00106.txt	2000/06/21 23:39:08	1.7
+++ ais/ai-00106.txt	2000/07/13 04:31:27	1.8
@@ -1,4 +1,4 @@
-!standard 13.14    (06)                               00-04-11  AI95-00106/09
+!standard 13.14    (06)                               00-07-11  AI95-00106/10
 !standard 13.14    (08)
 !standard 13.14    (11)
 !standard 13.14    (04)
@@ -13,7 +13,7 @@
 !priority High
 !difficulty Hard
 !qualifier Omission
-!subject Freezing Rules
+!subject Freezing rules
 
 !summary
 
@@ -27,7 +27,7 @@
 
 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
-via the Implementation Permissions in 7.6(18-21).
+via the implementation permissions in 7.6(18-21).
 
 4. If a name or expression is implicitly converted to a type or subtype,
 then that type or subtype is frozen at the same place where the name or
@@ -63,10 +63,10 @@
         type T(D: Integer) is ...;
     end P;
 
-Does the declaration of I freeze the type T?  If we replaced "Obj.D"
+Does the declaration of I freeze the type T? (Yes.) If we replaced "Obj.D"
 with "Obj.all.D", then it would freeze T, and therefore be illegal.
 
-13.14(11-11.b) says:
+13.14(11) says:
 
     At the place where a name
     causes freezing, the entity denoted by the name is frozen, unless
@@ -74,6 +74,8 @@
     object name causes freezing, the nominal subtype associated with
     the name is frozen.
 
+And AARM 13.14(11.a-11.b) say:
+
        Ramification:  This only matters in the presence of deferred
        constants or access types; an object_declaration other than a
        deferred_constant_declaration causes freezing of the nominal
@@ -86,7 +88,7 @@
 
 ----------------
 
-3. Does an implicit call to Initialize freeze the subprogram?  The
+3. Does an implicit call to Initialize freeze the subprogram? (Yes.) The
 freezing rules seem to apply to explicit constructs.  For example:
 
     type T is new Controlled with record...;
@@ -118,13 +120,9 @@
 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.
-
-   [At the place where a range
-   causes freezing, the type of the range is frozen.]
 
-        Proof:  This is consequence of the facts that expressions freeze
-        their type, and the Range attribute is defined to be equivalent
-        to a pair of expressions separated by ``..''.}
+   At the place where a range
+   causes freezing, the type of the range is frozen.
 
 Here's a case not covered by 13.14(12):
 
@@ -175,7 +173,7 @@
 names that denote objects, but it should -- the reasons for the
 existence of 13.14(8) apply equally to object names.
 
-Given the recommendation of this AI, the above example (1) is illegal.
+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
 the declaration of Y is an object_renaming_declaration, not an
@@ -206,8 +204,8 @@
 before My_Pool is completely defined.
 
 The problem occurs in any case where an object name can occur, and is
-analogous to the expression case in 13.14(8); hence the recommendation
-of this AI is worded by analogy with 13.14(8).
+analogous to the expression case in 13.14(8); hence the resolution
+is worded by analogy with 13.14(8).
 
 ----------------
 
@@ -218,14 +216,14 @@
 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 be a name (
-although it may be part of a name), it is added to 13.14(4).
+Since an implicit_dereference is not an expression and is not a name
+(although it may be part of a name), it is added to 13.14(4).
 
 ----------------
 
 3 and 4. Clearly implicit calls and implicit conversions should freeze
 in the same manner as their explicit counterparts.  An implicit call
-should freeze even if it is removed via the Implementation Permissions
+should freeze even if it is removed via the implementation permissions
 in 7.6(18-21); otherwise, there would be a portability problem.
 
 !corrigendum 13.14(4)