CVS difference for ais/ai-30359.txt

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

--- ais/ai-30359.txt	2004/10/05 22:49:28	1.2
+++ ais/ai-30359.txt	2004/11/24 00:09:43	1.3
@@ -1,4 +1,4 @@
-!standard 12.03     (02)                           04-09-23  AI95-00359-04/02
+!standard 12.03     (02)                           04-11-19  AI95-00359-04/03
 !standard 12.03.01  (01)
 !standard 13.14     (05)
 !class amendment 04-09-19
@@ -6,18 +6,18 @@
 !status received 04-09-19
 !priority Medium
 !difficulty Hard
-!subject Abstract generic instantations
+!subject Partial generic instantations
 
 !summary
 
 To better support generic signature packages, and mutually dependent types that
 involve generic instantiations, syntax is defined to allow a generic
-instantiation to be split into two parts, a partial "abstract" instantiation
-and a full/concrete (normal) instantiation.
+instantiation to be split into two parts, a partial instantiation
+and a full (normal) instantiation.
 
 For such a pair of instantiations, no freezing or elaboration occurs at the
-point of the abstract instantiation, rather it is deferred until the
-full/concrete instantiation which completes it.
+point of the partial instantiation, rather it is deferred until the
+full instantiation which completes it.
 
 !problem
 
@@ -121,7 +121,7 @@
 
 New section:
 
-  12.3.1 Abstract Package Instantiation
+  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
@@ -133,41 +133,24 @@
 
         Syntax
 
-    abstract_package_instantiation ::=
+    partial_package_instantiation ::=
       PACKAGE defining_identifier IS
-        ABSTRACT NEW generic_package_name abstract_instantiation_actual_part;
+        NEW generic_package_name generic_actual_part WITH PRIVATE;
 
-    abstract_instantiation_actual_part ::=
-        (<>)
-      | [generic_actual_part]
-      | ([generic_association {, generic_association},] OTHERS => <>)
-
-    Any positional generic_associations shall precede any named
-    generic_associations.
-
         Legality Rules
 
-  An abstract_package_instantiation declares an *abstract instance*; such a
+  A partial_package_instantiation declares a *partial 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
-  abstract_package_instantiation shall be a (concrete) package instantiation,
+  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 abstract instantiation). The completion shall declare an instance of
-  the same template; the abstract instance provides a *abstract view* of this
-  instance. If the abstract_instantiation_actual_part is (<>) or (OTHERS => <>),
-  there are no additional requirements on the completion; otherwise,
-  certain of the actual parameters of the completion shall match the
-  corresponding actual parameter of the abstract instantiation, determined as
-  follows:
-
-     * If the abstract_instantiation_actual_part includes generic_associations
-       as well as "OTHERS => <>", then only the actual parameters specified
-       explicitly in these generic_associations are required to match;
-
-     * Otherwise, all actual parameters shall match, whether the actual
-       parameter is given explicitly or by default.
+  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 rules for matching of actual parameters between the completion
   and the abstract instantiation are as follows:
@@ -189,7 +172,7 @@
 
       Static Semantics
 
-  The visible part of the abstract view includes the first list of
+  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
@@ -209,45 +192,13 @@
 
       Dynamic Semantics
 
-   Elaborating an abstact_package_instantiation has no effect.
+   Elaborating a partial_package_instantiation has no effect.
 
 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 abstract instantiations
+     completion.  Also see the freezing rules, where partial instantiations
      are defined to not cause freezing.
 
-Replace 12.7(2-10):
-
-       Syntax
-
-   formal_package_declaration ::=
-     WITH PACKAGE defining_identifier IS
-       NEW generic_package_name abstract_instantiation_actual_part;
-
-       Legality Rules
-
-   The generic_package_name shall denote a generic package (the *template* for
-   the formal package); the formal package is an instance of the template.
-
-   The actual shall be an instance of the template. Certain of
-   the actual parameters of the actual shall match the corresponding actual
-   parameter of the formal package. The matching required corresponds
-   to that required between the actual parameters of a completion of an
-   abstract_package_instantiation and those of the abstract instantiation (see 12.3.1).
-   For the purposes of matching, any actual parameter that is the name of
-   a formal object of mode IN is replaced by the formal object's actual
-   expression (recursively).
-
-       Static Semantics
-
-   A formal_package_declaration declares a generic formal package.
-
-   The visible part of a formal package includes the first list of
-   basic_declarative_items of the package_specification.  In addition, if one
-   or more actual parameters are not required to match, copies of declarations
-   from the formal part of the template are also included in the visible part
-   of the formal package, as for an abstract instance (see 12.3.1).
-
 Change 13.14(1) [suggested presentation improvement]:
 
    ... The Legality Rules [forbid certain kinds of uses of an entity in the
@@ -257,15 +208,15 @@
 
 Change 13.14(5):
 
-   * The occurrence of a generic_instantiation {other than an
-     abstract_package_instantiation} causes freezing{, no later than at
+   * The occurrence of a generic_instantiation {other than a
+     partial_package_instantiation} causes freezing{, no later than at
      the end of the instantiation}; ...
 
        AARM NOTE: When the definition of a composite type contains
          a component whose type is defined by an earlier
-         abstract_package_instantiation, and the "concrete" instantiation
+         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 concrete instantiation, by which
+         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
@@ -276,13 +227,13 @@
 
    ... 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, {an abstract_package_instantiation,} or a per-object
+   default_name, {a partial_package_instantiation,} or a per-object
    expression of a components's constraint, in which case[,] the freezing
    occurs later as part of another construct.
 
 Add after 13.14(18):
 
-   An entity with a view defined by a declaration within an abstract instance
+   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.
 
@@ -295,7 +246,7 @@
 
         type A is private;
 
-        package Inst is new abstract G(A, others => <>); -- abstract instantiation
+        package Inst is new G(A, X 3) with private; -- partial instantiation
 
     private
 
@@ -303,16 +254,10 @@
             X : Inst.B;
         end record;
 
-        package Inst is new G(A, X, 3); -- completion of abstract instantiation
+        package Inst is new G(A, X, 3); -- completion of partial instantiation
 
     end P;
 
-The abstract instantiation is like a formal package. It declares an instance
-by optionally specifying some or all of the actual parameters. The instance
-and its constituents are not "completely defined" until the full (concrete)
-instantiation is provided. Where the full instantiation is not visible, rules
-analogous to those for formal packages apply in terms of referring to
-unspecified actual parameters using the instance name as a prefix.
 
 !discussion
 
@@ -346,7 +291,7 @@
 the rule disallowing instantiations using private types prior to
 their completion, makes this impossible.
 
-Both of the above problems are solved by this abstract instantiation
+Both of the above problems are solved by this partial instantiation
 proposal.
 
 During the Ada 9X process, we observed that there is a relationship
@@ -357,15 +302,17 @@
 partial definition given in the visible part. This proposal is
 essentially taking what is provided by formal package parameters in a
 generic, and making an analogous capability available in a non-generic
-package. We have adopted the term "abstract" and "concrete" to match
-the chosen syntax, but it is essentially analogous to the partial/full
-view notion.
+package. Note that we require that all parameters be specified in
+the partial instantiations. We considered allowing partial parameter
+specification analogous to what is permitted with formal packages, but
+this seemed to add significant implementation complexity without significant
+benefit.
 
 One concern which arose during review of this proposal was that if there
 are multiple components within a composite type each of which requires its own
 instantiation taking the composite type as an actual, at most one of them
 can be a "direct" component -- the others must be of an
-access type. That is because the first "concrete"
+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
 conclusion was that this was not a severe limitation, as using the

Questions? Ask the ACAA Technical Agent