CVS difference for ais/ai-00359.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00359.txt

--- ais/ai-00359.txt	2004/04/06 19:57:16	1.4
+++ ais/ai-00359.txt	2004/06/10 04:21:51	1.5
@@ -1,4 +1,4 @@
-!standard 12.03     (12)                               03-09-29  AI95-00359/02
+!standard 12.03     (12)                               04-06-07  AI95-00359/03
 !standard 12.03     (20)
 !standard 13.14     (05)
 !class amendment 03-07-22
@@ -14,25 +14,17 @@
 To better support generic signature packages, and
 mutually dependent types that involve generic instantiations,
 it is proposed that a generic instantiation not cause
-freezing immediately if any of its actual parameters
-are types that have not been completely defined.
+freezing until specified if a Deferred_Freezing_Point pragma applies
+to the instantiation.
 
 For such an instantiation, no special freezing happens
 at the point of the instantiation, other than the freezing
 that is due to the elaboration of the declarations within
-the "spec" of the instantiation. Elaboration of the body
-of the instantiation is deferred until a "general" freezing
-point occurs, which occurs at the end of the enclosing
-library unit or declarative part, upon encountering a "real" body, etc.
+the "spec" of the instantiation. The freezing of the
+instantiation as a whole takes place at the place of the
+pragma, at which point the instance is frozen and the
+instance body is elaborated.
 
-NOTE: This more "relaxed" freezing and deferred body elaboration
-could be used for all generic instantiations, but that could
-create some incompatibilities, since we would be altering
-the point when the body of the instantiation was elaborated.
-This proposal is guaranteed to be upward compatible, since
-only instantiations that are currently illegal would be
-using "relaxed" freezing and deferred body elaboration.
-
 !problem
 
 Ada 95 provides formal package parameters. One way of using
@@ -133,40 +125,52 @@
 (See summary.)
 
 !wording
+
+Add after 13.14(19/1):
+
+    The Deferred_Freezing_Point pragma may be used to specify a deferred point
+    where the freezing caused by a generic_instantiation takes place. The
+    elaboration of the instance body is also deferred to this point.
+
+         Syntax Rules
+
+    The form of a pragma Deferred_Freezing_Point is as follows:
+
+        pragma Deferred_Freezing_Point(generic_instantiation_local_name);
+
+         Static Semantic Rules
 
-Change paragraph 12.3(12) as follows:
-   A generic_instantiation declares an instance; it is equivalent to the
-   instance declaration (a package_declaration or
-   subprogram_declaration) followed [immediately] by the instance body[,
-   both at the place of the instantiation]. {The instance declaration
-   is located at the place of the instantiation. The instance body is
-   located immediately following the instance declaration if none of the
-   actual parameters denote types that are not yet completely defined.
-   If one of the actual parameters denotes a type not completely
-   defined, the location of the instance body is immediately prior to
-   the next non-instance body, or the end of the nearest enclosing
-   declarative_part or library_item.}
-
-Change paragraph 12.3(20) as follows:
-   ... Finally, the instance declaration [and body are] {is} elaborated.
-   {The instance body is elaborated either immediately following the
-   instance declaration, or deferred until the next non-instance body or
-   end of the enclosing declarative_part or library_item if there are
-   any actuals that denote types that are not yet completely defined.}
-
-Change paragraph 13.14(5) as follows:
-  * The occurrence of a generic_instantation causes freezing {except
-    when one of the actual parameters denotes a type that is not yet
-    completely defined}; also, if a parameter of [the] {an}
-    instantiation {that causes freezing} is defaulted, the
-    default_expression or default_name for that parameter causes
-    freezing. {For an instantiation that does not cause freezing, the
-    constructs of the instance declaration cause freezing according to
-    the rules of this clause. The elaboration of the instance body is
-    deferred until the end of an enclosing construct or a non-instance
-    body which would cause freezing of all enclosed or prior
-    declarations.}
+    In the absence of a pragma Deferred_Freezing_Point, the occurrence
+    of a generic_instantiation immediately causes freezing. However, if
+    a pragma Deferred_Freezing_Point applies to the instantiation, the
+    freezing is deferred to the place of the pragma. The only freezing
+    that takes place at the point of the instantiation is that
+    associated with the constructs of the instance declaration.
 
+         Legality Rules
+
+    A pragma Deferred_Freezing_Point that applies to a given
+    generic_instantiation shall preceed any construct (outside the
+    instance itself) that causes freezing of an entity defined by the
+    generic_instantiation.
+
+         Dynamic Semantic Rules
+
+    In the absence of a pragma Deferred_Freezing_Point, the elaboration
+    of an instance body takes place immediately after elaborating the
+    instance declaration, at the point of the generic_instantiation.
+    However, if a pragma Deferred_Freezing_Point applies to the
+    instantiation, the elaboration of the instance body is deferred to
+    the place of the pragma.
+
+  AARM NOTE:
+
+    Even though elaboration of the instance body is deferred, no freezing
+    reference to an entity defined by the instantiation is permitted, and hence
+    no calls on such an entity nor other uses that might result in an access
+    before elaboration error can occur prior to the elaboration of the
+    instance body.
+
 !example
 
 (See problem.)
@@ -189,6 +193,17 @@
 completely restructure things to be able to use a generic
 container as part of defining a private type.
 
+We considered making the freezing occur on first freezing reference to
+an entity defined by the instantiation, but that would make the
+point of elaboration of the instance body dependent on the
+mysteries of the freezing rules. Here we make the location of
+the pragma itself the point where freezing and body elaboration
+take place.
+
+Because elaboration of the instance body occurs at the same point as
+freezing, implementations may continue to omit "elaboration bits" for
+subprograms defined by an instantiation.
+
 --!corrigendum 13.14(05)
 
 !ACATS test
@@ -1805,6 +1820,44 @@
 freezing-type rule here would mean that it would not be safe to change the
 implementation of a generic unit for fear that it would break existing code.
 That would be a bad policy for Ada to adopt.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 7, 2004  10:42 PM
+
+Here is an update to AI-359-01. [This is version /03 of the AI - ED]
+It provides a pragma Deferred_Freezing_Point which when applied
+to a generic_instantiation, defers both freezing
+and instance body elaboration to the point of the
+pragma.  We had talked about deferring to the first point
+when some freezing reference was made to an entity
+defined by the instantiation, but that made the
+point where instance body elaboration occurred
+subject to the mysteries of the freezing rules.
+So I made the freezing and elaboration happen
+at the point of the pragma itself, which seems
+to eliminate that problem, and should provide
+sufficient flexibility.  In general, one would
+place the pragma after all the types
+passed as actuals to the instantiation had been
+completely defined.
+
+The net effect is that the freezing rules affect
+legality, but do not affect the dynamic semantics,
+since the instance body elaboration is based on the
+location of the pragma, rather than on when the
+first freezing reference to the instance occurs.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 8, 2004  1:55 AM
+
+Is this pragma only allowed for instantiations which are packages?  I can't
+seem to find this in the AI.  Obviously for an instantiation which is a
+subprogram the local_name is not enough to denote a particular
+instantiation.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent