CVS difference for ais/ai-60217.txt

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

--- ais/ai-60217.txt	2003/06/17 21:48:37	1.4
+++ ais/ai-60217.txt	2003/06/18 00:12:25	1.5
@@ -14,27 +14,27 @@
 
 A new form of incomplete type declaration is provided for
 specifying that a type is to be completed in a child or nested
-package.  This enables a set of mutually dependent type definitions
+package. This enables a set of mutually dependent type definitions
 to cross packages that are part of a package hierarchy.
 
 !problem
 
-Ada 95 does not allow two package specs to depend on each other.  This
+Ada 95 does not allow two package specs to depend on each other. This
 can cause problems when creating Ada packages to use in interfacing with code
-written in languages like Java.  In Java, there are no restrictions against
-mutually dependent class definitinos.  When expressed in Ada, this means
+written in languages like Java. In Java, there are no restrictions against
+mutually dependent class definitinos. When expressed in Ada, this means
 that a package may define a type which is used in a second package's spec,
-while also making use of a type defined in that package spec.  This is
+while also making use of a type defined in that package spec. This is
 clearly not allowed due to restrictions against cyclic semantic dependences.
 Cyclic semantic dependences cannot generally be allowed in Ada because of
 the order of elaboration requirements.
 
 This problem also can occur when organizing large object-oriented systems
-solely in Ada 95.  The "solution" is to place all of the types in a single
-package.  However, the rules for defining primitive operations of a type
+solely in Ada 95. The "solution" is to place all of the types in a single
+package. However, the rules for defining primitive operations of a type
 require that most of the operations of the type also must be declared in
-the package.  This leads to gigantic packages.  An alternative solution is
-to add additional indirection into the data structures.  This adds complexity
+the package. This leads to gigantic packages. An alternative solution is
+to add additional indirection into the data structures. This adds complexity
 as well as space and time costs at runtime.
 
 !proposal
@@ -52,11 +52,11 @@
 
     An incomplete_type_declaration requires a completion, which shall be
     a full_type_declaration {, a private_type_declaration, or a
-    private_extension_declaration}.  {If a package_identifier
+    private_extension_declaration}. {If a package_identifier
     is present in the declaration, the completion shall occur immediately
     within the visible part of a package with this identifier,
     which shall be declared later and immediately within the innermost
-    enclosing declarative region.  Otherwise, if}[If] the
+    enclosing declarative region. Otherwise, if}[If] the
     incomplete_type_declaration  occurs immediately within ...
 	< rest remains the same >.
 
@@ -92,7 +92,7 @@
     then the enclosing package shall be a library unit, and the named package
     shall be a child of this library package (see 10.1.1).
     Furthermore, if the incomplete type is declared in the visible part,
-    then the named package shall be a public child.  In either case, the
+    then the named package shall be a public child. In either case, the
     named child package is needed in a partition (see 10.2) that includes the
     enclosing library package.
 
@@ -100,15 +100,15 @@
 
     If a package_identifier is present in the declaration, the
     incomplete type is declared immediately within the declarative
-    region of the named package.  Otherwise, the incomplete type is
+    region of the named package. Otherwise, the incomplete type is
     declared immediately within the innermost enclosing declarative region.
 
 Add the following paragraph after 3.10.1(11):
 
     If places where one or more incomplete_type_declarations are visible which
     include the same package_identifier, a view of the named package
-    is visible with this identifier.  The view includes only the incomplete
-    types named in these incomplete_type_declarations.   [Note that in places
+    is visible with this identifier. The view includes only the incomplete
+    types named in these incomplete_type_declarations. [Note that in places
     where the package_declaration or a library_unit_renaming_declaration for
     this package is visible, all of the incomplete_type_declarations will
     be hidden from all visibility.]
@@ -123,7 +123,7 @@
     If the completion of a declaration is a declaration, then [within
     the scope of] {in places where} the completion {is visible}, the
     first declaration [is] {, and any declarations it completes, are}
-    hidden from all visibility.  Similarly, a discriminant_specification
+    hidden from all visibility. Similarly, a discriminant_specification
     or parameter_specification is hidden [within the scope of]
     {in places where} a corresponding discriminant_specification
     or parameter_specification of a corresponding completion, or
@@ -205,7 +205,7 @@
 be a child in the above example, so it can be defined
 directly as package "Employees" rather than
 as package "Office.Employees," eliminating the need
-for the first renaming.  In this case, package "Office"
+for the first renaming. In this case, package "Office"
 might better be called something else, since it no longer
 encapsulates the entire "office" abstraction.
 E.g., it might be called simply "Forward":
@@ -242,7 +242,7 @@
 -------------------
 (d) One option not fully analyzed would be to allow the
 incomplete type to be completed by a type within
-a package renaming.  This might require somewhat different
+a package renaming. This might require somewhat different
 wording changes, but this is how the above example would look.
 Note that now the packages are both defined as top-level
 library packages, and the only child unit is a renaming:
@@ -283,10 +283,10 @@
 
 This proposal attempts to address the need to have types that
 are mutually dependent which are not all defined in the same
-library package.  The approach is built upon the idea that
+library package. The approach is built upon the idea that
 any group of types that are mutually dependent are necessarily
 part of a single logical abstraction, and hence will often
-be declared as part of a package hierarchy.  We take advantage
+be declared as part of a package hierarchy. We take advantage
 of this by placing the incomplete type declaration in the
 root package of the abstraction, and then the types that are mutually
 dependent can be declared in this same package, or in its
@@ -295,32 +295,32 @@
 The proposed syntax is intended to be analogous to the syntax
 used for declaring child units, and in fact was discussed
 during the Ada 9X design process as a natural extension
-of deferred incomplete types.  The problem in the Ada 9X
+of deferred incomplete types. The problem in the Ada 9X
 process was we only considered allowing the declaration in
-the private part of the parent.  That, unfortunately, doesn't
-solve the mutually dependent type problem.  By allowing
+the private part of the parent. That, unfortunately, doesn't
+solve the mutually dependent type problem. By allowing
 this generalized incomplete type declaration in the visible
 part of the parent, we have completed the process of allowing
 a large abstraction to be spread across multiple packages
 in a hierarchy.
 
 In fact, the proposal is not restricted to packages in a hierarchy,
-though that is one anticipated style of usage.  Only the
+though that is one anticipated style of usage. Only the
 package that breaks the cycle need be declared as a child.
 All the other packages can be declared as top-level library units,
 as illustrated in the first "package Forward" example above (example (c)).
 
 Note that this proposal allows the completing type to be
-defined in an instantiation.  The second "package Forward" example
+defined in an instantiation. The second "package Forward" example
 (example (d)) illustrates a further option, where we would allow the
-type to be "completed" in a renaming.  Although this option
+type to be "completed" in a renaming. Although this option
 has not been fully investigated, it has the interesting
 effect of allowing all the package declarations to be
-top-level, and only the renaming is a child.  This option
+top-level, and only the renaming is a child. This option
 might resolve some of the concerns about being forced to
 declare one or more packages as children.
 
-The wording change to 8.3(19) deserves some extra discussion.  The change
+The wording change to 8.3(19) deserves some extra discussion. The change
 from "within the scope" to "places where visible" seems necessary for
 any of our proposals, to avoid the "ripple" effect where an indirect "with"
 dependence can have significant effects on a unit outside the
@@ -329,25 +329,25 @@
 The original "within scope" wording would pull completions
 into all semantic dependents of the completing package, since the
 scope of a library item extends to all its dependents, including
-those units that do not have "with" visibility on the _item.  But
+those units that do not have "with" visibility on the _item. But
 we have agreed in past discussions that we want the completing
 package (or a library rename thereof) to be visible, not just somewhere
 within scope, if we are going to consider the type "completed."
 The new wording of the paragraph is intended to have no effect
 on existing code.
 
-Note the addition to 8.5.3.  We want non-library-unit renamings to
+Note the addition to 8.5.3. We want non-library-unit renamings to
 provide the same view as whatever other view we already have of
 a package, whereas an explicit "with" of a library-unit renaming should
-always show at least the entire visible part.  We believe that this
+always show at least the entire visible part. We believe that this
 revision of the wording accomplishes this (albeit a bit wordily).
 Basically, we want one and only one view of a package at any given
 place, no matter what name is used to identify the package.
 
-One note about the syntax, to address Randy's concern.  Adding the
+One note about the syntax, to address Randy's concern. Adding the
 optional "[package_identifer.]" to the syntax could be treated by the
 parser roughly in the same way as the optional "[parent_unit_name.]"
-is treated in section 6.1 for defining_unit_name.  You could allow
+is treated in section 6.1 for defining_unit_name. You could allow
 this prefix on any type declaration, and then have a semantic
 rule that makes sure it is only used for incomplete type
 declarations.

Questions? Ask the ACAA Technical Agent