CVS difference for ais/ai-20217.txt

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

--- ais/ai-20217.txt	2002/02/07 04:56:42	1.7
+++ ais/ai-20217.txt	2003/06/18 00:12:24	1.8
@@ -1823,3 +1823,162 @@
 
 *************************************************************
 
+From: Nick Roberts
+Sent: Monday, March 3, 2003,  6:09 PM
+
+
+I would like to make a proposal only slightly different to AI 217-03. I
+believe it is a little bit simpler, whilst still achieving the necessary
+effect.
+
+I propose that one new form of type declaration is introduced, the "separate
+type declaration", which is very heavily based on the 'separate incomplete
+type' suggested in AI 217-03.
+
+A new production called "separate_type_declaration" needs to be added:
+
+   separate_type_declaration ::=
+      TYPE defining_identifier discriminant_part IS SEPARATE;
+
+as well as :
+
+   separate_type_completion ::= full_type_declaration
+      | incomplete_type_declaration
+      | private_type_declaration
+      | private_extension_declaration
+
+The syntax production for a type declaration (RM 3.2.1 (2)) needs to be
+extended:
+
+   type_declaration ::= full_type_declaration
+      | incomplete_type_declaration
+      | private_type_declaration
+      | private_extension_declaration
+      | separate_type_declaration
+
+The defining identifier within the syntax productions for a full type
+declaration, task type declaration, protected type declaration, incomplete
+type declaration, private type declaration, and private extension
+declaration needs to be replaced by a production name which denotes either a
+defining identifier or a name. Possibly:
+
+   completion_name_or_defining_identifier ::= completion_name |
+defining_identifier
+
+   completion_name ::= name
+
+The following rules need to be added:
+
+(1) A separate type declaration is only allowed directly within the visible
+part of a package specification, and it declares an entity called a
+"separate type", which is a view of a type. The only allowed uses of a
+separate type are the same as those for an incomplete type (RM 3.10.1
+(5-9)), plus completion as described below.
+
+(2) A separate type is completed by a separate type completion in the
+visible part of another package specification which has a completion name
+(fully qualified as necessary) that denotes the separate type. The name must
+be visible according to the usual rules (its package must be 'with'ed). The
+completion and separate type both denote the same type, but are different
+views of that type.
+
+(3) If the separate type declaration has a known discriminant part, then the
+separate type completion must have a fully conforming known discriminant
+part (cf RM 3.10.1 (4)).
+
+(4) Since the same name can denote both a separate type and its completion,
+the name is interpreted as the completion wherever its declaration is
+visible (even if the separate type's declaration is also visible), and as
+the separate type otherwise (whose declaration must be visible, according to
+the usual rules).
+
+(5) If a separate type is declared in a trans-partitional package (including
+shared passive, remote call interface, and remote types library units), it
+must have at most one completion in a program; within the program, the
+separate type and its completion denote the same type.  If a separate type
+is not declared in a trans-partitional package, it must have at most one
+completion in a partition; within the partition, the separate type and its
+completion denote the same type (and neither can be seen outside the
+partition).
+
+The familiar example of employees and departments could be formulated as
+below.
+
+    package Partial_Definitions is
+       type Employee (<>) is separate;
+       type Emp_Ptr is access Employee;
+       type Department (<>) is separate;
+       type Dpt_Ptr is access Department;
+   end Partial_Definitions;
+
+   with Partial_Definitions;
+   package Employees is
+      type Partial_Definitions.Employee is private;
+      subtype Employee is Partial_Definitions.Employee;
+      procedure Assign_Employee
+         (Emp : in out Employee;
+          Dpt : access Partial_Definitions.Department);
+        ...
+       function Current_Department
+         (Dpt : in Employee) return Partial_Definitions.Dpt_Ptr;
+   private
+      type Partial_Definitions.Employee is
+         record
+            Name : ...;
+            Dept : Partial_Definitions.Dpt_Ptr;
+            ...
+         end record;
+      ...
+   end Employees;
+
+   with Partial_Definitions;
+   package Departments is
+      type Partial_Definitions.Department is private;
+      subtype Department is Partial_Definitions.Department;
+       procedure Choose_Manager
+         (Dpt : in out Department;
+          Man : access Partial_Definitions.Employee);
+        ...
+   private
+      ...
+   end Departments;
+
+Note how subtype declarations are used to provide convenient alternative
+names for the completed types.
+
+Operations declared directly in the same package specification as a full
+type which completes a separate type, and which have it as a parameter or
+return type, are (still) primitive operations of the type.
+
+An access type whose designated type is a separate type /does/ have a
+(default) pool, which is a standard pool. However this pool may, of course,
+be different (to that which would have been selected if the designated type
+were not separate), and the implementation of the access type may, of
+course, also be different. In particular, the pool selected may change if
+the configuration of the partition (or program) is changed (without actually
+recompiling anything, although presumably requiring relinking).
+
+One interesting subtlety of my proposal as it stands is that a separate type
+can be completed by an incomplete type declaration! This will probably not
+be useful in practice, but I see no reason to exclude it.
+
+You will note that I have required a discriminant part in the separate type
+declaration syntax. I prefer this: the separate type has either known
+discriminants (and has a known discriminant part) or an unknown constraint
+(and has an unknown discriminant part "(<>)").
+
+I would like to add the proposal that the next revision deprecates the form
+of incomplete type declaration (RM 3.10.1 (2)) which omits the discriminant
+part altogether (in preparation for its disallowal in the revision after
+that).
+
+One final proposal. RM 3.10.1 (9) permits the Class attribute to be added to
+the name of an incomplete type. However, if this is done, the incomplete
+type must be completed by a tagged type. I propose that it does not have to
+be completed by a tagged type, and furthermore that the definition of the
+Class attribute be changed to make S'Class equivalent to S'Base for every
+subtype S which is not tagged (thus making the attribute applicable to all
+subtypes).
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent