CVS difference for ais/ai-30359.txt

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

--- ais/ai-30359.txt	2004/11/24 00:09:43	1.3
+++ ais/ai-30359.txt	2004/11/24 00:18:33	1.4
@@ -1,4 +1,4 @@
-!standard 12.03     (02)                           04-11-19  AI95-00359-04/03
+!standard 12.03     (02)                           04-11-20  AI95-00359-04/04
 !standard 12.03.01  (01)
 !standard 13.14     (05)
 !class amendment 04-09-19
@@ -6,7 +6,7 @@
 !status received 04-09-19
 !priority Medium
 !difficulty Hard
-!subject Partial generic instantations
+!subject Partial view of generic instantiations
 
 !summary
 
@@ -109,24 +109,38 @@
 
 !proposal
 
-(See summary.)
+We are proposing syntax to allow package instantiations to be split into two parts,
+a partial package instantiation and a full (normal) instantiation.
+For such a pair of instantiations, no freezing or elaboration occurs at the
+point of the partial package instantiation, rather freezing and elaboration are
+deferred until the full instantiation which completes it.
+
+The syntax of the partial package instantiation follows the following form:
+
+   package P is new G(Priv_Type) with private;
 
+This syntax, based on that used for private extensions,
+is intended to convey that the instance is a partial view. Between
+the partial package instantiation and the full package instantiation,
+the entities declared by the instance are not completely defined,
+and hence cannot be used in contexts that cause freezing.
+
 !wording
 
 Add to 12.3(2):
 
     generic_instantiation ::=
         ...
-      | abstract_package_instatiation
+      | partial_package_instantiation
 
 New section:
 
   12.3.1 Partial Package Instantiation
 
-  An abstract package instantiation can be used to declare an abstract view of
-  a package instance. A corresponding (concrete) package instantiation provides
-  the concrete view of the instance. In contrast to a concrete instantiation,
-  the actual parameters to an abstract package instantiation
+  A partial package instantiation can be used to declare a partial view of
+  a package instance. A corresponding (full) package instantiation provides
+  the full view of the instance. In contrast to a full instantiation,
+  the actual parameters to a partial package instantiation
   may be private types or extensions prior to their full definition, allowing
   mutual dependence between a type defined within an instance and the full definition
   of its actual parameter types.
@@ -139,21 +153,21 @@
 
         Legality Rules
 
-  A partial_package_instantiation declares a *partial instance*; such a
+  A partial_package_instantiation declares a *partial package instance*; such a
   declaration is allowed only as a declarative_item of the visible or private
-  part of a package, and it requires a completion. The completion of an
+  part of a package, and it requires a completion. The completion of a
   partial_package_instantiation shall be a (full) package instantiation,
   and shall appear later within the private part of the enclosing package.
 
-  The generic_package_name shall denote a generic package (the *template*
-  for the partial instantiation). The completion shall declare an instance of
-  the same template; the partial instance provides a *partial view* of this
-  instance. The actual parameters of the completion shall match the
-  corresponding actual parameter of the partial instantiation, whether the
-  actual parameter is given explicitly or by default.
+  The generic_package_name shall denote a generic package (the *template* for
+  the partial package instantiation). The completion shall declare an instance
+  of the same template; the partial package instance provides a *partial view*
+  of this instance. The actual parameters of the completion shall match the
+  corresponding actual parameter of the partial package instantiation, whether
+  the actual parameter is given explicitly or by default.
 
   The rules for matching of actual parameters between the completion
-  and the abstract instantiation are as follows:
+  and the partial instantiation are as follows:
 
      * For a formal object of mode IN the actuals match if they are
        static expressions with the same value, of if they statically
@@ -166,28 +180,22 @@
        identify the same entity.
 
 AARM NOTE: We considered using full conformance rules here instead of
-    formal-package-ish matching. However, we wanted to share the rules
+    formal-package-ish matching. However, we wanted to use rules consistent
     with formal packages, and it seemed simpler to just define the particular
-    matching rules needed between instantiations.
+    matching rules needed between instantiations. Also we wanted to
+    ensure that no evaluations would take place at the point of the
+    partial package instantiation.
 
       Static Semantics
 
-  The visible part of the partial view includes the first list of
-  basic_declarative_items of the package_specification. In addition,
-  for each actual parameter that is not required to match, a copy of the
-  declaration of the corresponding formal parameter of the template is
-  included in the visible part of the partial view. If the copied
-  declaration is for a formal type, copies of the implicit declarations
-  of the primitive subprograms of the formal type are also included in
-  the visible part of the partial view.
-
-  The declarations within an abstract instance provide views of the
-  entities declared by the corresponding declaration within the concrete
-  instance. Prior to this corresponding declaration, certain restrictions
+  The declarations within a partial package instance provide views of the
+  entities declared by the corresponding declaration within the full
+  instance. The view is static only if the entity was static in the template.
+  Prior to this corresponding declaration, certain restrictions
   apply to the use of these views (see 13.14). After the corresponding
-  declaration,  these views are the same as those defined by this corresponding
-  declaration. Prior to the full definition of the type in the concrete
-  instance, a type declared within an abstract instance is not completely
+  declaration, these views are the same as those defined by this corresponding
+  declaration. Prior to the full definition of the type in the full
+  instance, a type declared within a partial package instance is not completely
   defined.
 
       Dynamic Semantics
@@ -196,32 +204,25 @@
 
 AARM NOTE: We considered requiring evaluation of the actuals here, but
      that would disallow passing deferred constants prior to their
-     completion.  Also see the freezing rules, where partial instantiations
+     completion. Also see the freezing rules, where partial instantiations
      are defined to not cause freezing.
 
 Change 13.14(1) [suggested presentation improvement]:
 
    ... The Legality Rules [forbid certain kinds of uses of an entity in the
    region of text where it is frozen] {require that any declarative_item or
-   pragma that might affect the representation of an entity occur prior to it
+   pragma that might affect the representation of an entity occur prior to its
    becoming frozen}.
 
 Change 13.14(5):
 
    * The occurrence of a generic_instantiation {other than a
-     partial_package_instantiation} causes freezing{, no later than at
-     the end of the instantiation}; ...
+     partial_package_instantiation} causes freezing; ...
 
-       AARM NOTE: When the definition of a composite type contains
-         a component whose type is defined by an earlier
-         partial_package_instantiation, and the "full" instantiation
-         takes the composite type as a formal, we don't want the composite
-         type frozen until the end of the full instantiation, by which
-         point the component's type will be completely defined. However, the
-         composite type might be frozen earlier within the instantiation,
-         if some sort of freezing reference is made to it, such as taking
-         the 'Size of the formal before completing the definition of the
-         (component's) type defined by the instantiation.
+       AARM NOTE: The freezing rules still preclude declaring a composite
+         type with a direct component whose type is defined by an earlier
+         partial_package_instantiation if the full instantiation
+         takes the composite type as a formal.
 
 Change 13.14(8/1):
 
@@ -233,12 +234,12 @@
 
 Add after 13.14(18):
 
-   An entity with a view defined by a declaration within a partial instance
-   shall not be frozen prior to the occurrence of the corresponding declaration
-   in the concrete instance.
+   An entity with a nonstatic view defined by a declaration within a partial
+   instance shall not be frozen prior to the occurrence of the corresponding
+   declaration in the full instance.
 
      AARM NOTE: Even after this corresponding declaration, other rules
-       may still disallow freezing, but these are the "normal" freezing rules.
+       may still disallow freezing, but these are the normal freezing rules.
 
 !example
 
@@ -246,7 +247,7 @@
 
         type A is private;
 
-        package Inst is new G(A, X 3) with private; -- partial instantiation
+        package Inst is new G(A, X, 3) with private; -- partial package instantiation
 
     private
 
@@ -254,7 +255,7 @@
             X : Inst.B;
         end record;
 
-        package Inst is new G(A, X, 3); -- completion of partial instantiation
+        package Inst is new G(A, X, 3); -- completion of partial package instantiation
 
     end P;
 
@@ -263,15 +264,11 @@
 
 It is a frustrating limitation to the use of generics, particularly as
 containers and signatures, that they cannot be instantiated using a
-private type prior to its completion. It is relatively common where a
-type directly or indirectly contains a subcomponent that gives access
-back to an object of the enclosing type. When using generics to provide
-abstraction, access types are often buried within the abstraction rather
-than making them a visible part of the abstraction. When taking this
-approach to implement, for example, a set of objects, it is then
-perfectly reasonable for a type T to include as a component a type
-representing a "set" of type T. However, the current restrictions on
-generics make this impossible.
+private type prior to its completion. For example, if one establishes a
+"Map" signature, it would be natural for the Hashed_Map generic and the
+Ordered_Map generic to both include instantiations of the Map signature
+within their visible part. However, the rule disallowing instantiations
+using private types prior to their completion, makes this impossible.
 
 The other important use of an instantiation where the actual is a
 private type is for "signature" generics. Such generics allow an
@@ -285,12 +282,6 @@
 has no clear way to specify that the generic is declaring an abstraction
 that is consistent with the signature.
 
-For example, if one establishes a "Map" signature, it would be natural
-for the Hashed_Map generic and the Ordered_Map generic to both include
-instantiations of the Map signature within their visible part. However,
-the rule disallowing instantiations using private types prior to
-their completion, makes this impossible.
-
 Both of the above problems are solved by this partial instantiation
 proposal.
 
@@ -300,7 +291,7 @@
 In the generic, the actual parameter "completes" the formal, whereas in
 the package, the full definition in the private part "completes" the
 partial definition given in the visible part. This proposal is
-essentially taking what is provided by formal package parameters in a
+essentially taking some of what is provided by formal package parameters in a
 generic, and making an analogous capability available in a non-generic
 package. Note that we require that all parameters be specified in
 the partial instantiations. We considered allowing partial parameter
@@ -314,7 +305,7 @@
 can be a "direct" component -- the others must be of an
 access type. That is because the first "full"
 instantiation needed for one of the component types will freeze the
-composite type, and thence freeze all the (direct) component types.  The
+composite type, and thence freeze all the (direct) component types. The
 conclusion was that this was not a severe limitation, as using the
 result of an instantiation as a direct component type was in some sense
 "breaking" privacy, since it was assuming that the generic defining the
@@ -328,10 +319,12 @@
 having an instance of itself as a component. On the other hand, using
 "access set_of_T" for the component of T would always be safe.
 
-In the case where the author of the generic defining the component type
-is also the author of the composite type definition, and there is
-presumed close linkage between the two, this proposal still allows
-the direct embedding for one such component type.
+We considered allowing the direct embedding of one such component type.
+This would be a case where the author of the generic defining the
+component type is also the author of the composite type definition, and
+there is presumed close linkage between the two. However, this required
+"piecemeal" freezing during the full instantiation, and also was a
+privacy breakage, and so we chose not to provide this capability.
 
 No similar problem exists for signature packages, as these typically
 do not define new types. For such packages, the key feature is to be

Questions? Ask the ACAA Technical Agent