CVS difference for ais/ai-50217.txt

Differences between 1.12 and version 1.13
Log of other versions for file ais/ai-50217.txt

--- ais/ai-50217.txt	2004/01/23 04:59:29	1.12
+++ ais/ai-50217.txt	2004/05/29 00:38:44	1.13
@@ -1,4 +1,4 @@
-!standard 10.01.01   (12)                           04-01-09  AI95-00217-06/07
+!standard 10.01.01   (12)                           04-05-21  AI95-00217-06/08
 !standard 10.01.01   (26)
 !standard 10.01.02   (04)
 !standard 10.01.02   (06)
@@ -41,7 +41,7 @@
 
 !proposal
 
-A new kind of with_clause is added, of the form "limited with <library
+A new kind of with_clause is added, of the form "limited with <list of library
 package names>;". This is called a "limited_with_clause". The old
 fashioned kind is called a "nonlimited_with_clause".
 
@@ -52,12 +52,12 @@
       elaboration dependence on X). The implementation may choose to
       elaborate X either before or after the current unit.
 
-    - Instead of providing visibility to the named packages and their
-      content, it provides visibility only to the package names, any
-      packages nested within them, and a view of each type therein.
-      The type view is incomplete, implying all the usual restrictions
-      on incomplete types. If the type is tagged, the view is tagged
-      incomplete.
+    - Instead of providing visibility of the named packages and their
+      content, it provides visibility of only the names of the packages and
+      the packages nested within them, and an incomplete view of all types in
+      the packages and nested packages. Such incomplete views imply the
+      usual restrictions on incomplete types. If the type is tagged, the view
+      is tagged incomplete.
 
 Thus, cyclic chains of with_clauses are allowed, so long as the chain is
 broken by at least one limited_with_clause.
@@ -76,14 +76,14 @@
 o  its expected type is the completion of T.
 
 <Author's note: this wording is provisional; final wording will be provided by
-AI 326, which is expected to define incomplete types in terms of views.>
+AI-326, which is expected to define incomplete types in terms of views.>
 
 
 Replace 4.1(9) by:
 
 If the type of the name in a dereference is some access-to-object type T, then
 the dereference denotes a view of an object. The nominal subtype of that view
-view is the designated subtype D of T, unless D is an incomplete type, in which case
+is the designated subtype D of T, unless D is an incomplete type, in which case
 the nominal subtype is the completion of D.
 
 <Author's note: same comment as for 3.10.1(10), above.>
@@ -101,7 +101,7 @@
 
 Replace 8.4(5) by:
 
-A package_name of a use_package_clause shall denote a non-limited view of a
+A package_name of a use_package_clause shall denote a nonlimited view of a
 package.
 
 
@@ -123,7 +123,7 @@
 
 Replace 8.5.3(3) by:
 
-The renamed entity shall be a non-limited view of a package.
+The renamed entity shall be a nonlimited view of a package.
 
 
 Add after 10.1.1(12):
@@ -154,12 +154,12 @@
 _not_ the declaration of a library unit (the library package_declaration is);
 nonetheless, it is a library_item.
 
-A library package_declaration is the completion of its limited view
-declaration.
+A library package_declaration is the completion of the declaration of its
+limited view.
 
 The elaboration of the limited view of a package has no effect.
 
-Insert somewhere in 10.1.1(26):
+Insert in 10.1.1(26):
 
 The implicit declaration of the limited view of a library package depends
 semantically upon the implicit declaration of the limited view of its parent.
@@ -223,20 +223,20 @@
 
 !discussion
 
-It is natural to think of a with_clause as causing a library unit to
-become visible. However, that's not what the RM says. Instead, the RM
-says that *lack* of a with_clause causes a library unit *not* to be
-visible. That's kind of odd, but to understand the wording, you have to
-understand the existing model in this language-lawyerly fashion.
-
-The current RM defines the notion of an "environment declarative_part".
-During compilation, this fanciful declarative_part is imagined to
-contain all the library_items of interest. The order of these
+It is natural to think of a with_clause as causing a library unit to become
+visible. However, that's not what the Standard says. Instead, the Standard says
+that *lack* of a with_clause causes a library unit *not* to be visible. That's
+kind of odd, but to understand the wording, you have to understand the existing
+model in this way.
+
+The Standard (in 10.1.4(1)) defines the notion of an "environment
+declarative_part". During compilation, this fanciful declarative_part is
+imagined to contain all the library_items of interest. The order of these
 library_items is such that there are no forward semantic dependences.
 With_clauses introduce semantic dependences, so they control the order.
-Semantic dependences are also caused by child-parent and body-spec
-relationships. Subunits are imagined to be "inlined" at their stub
-point, so subunits can be ignored for visibility purposes.
+Semantic dependences are also caused by child-parent and body-specification
+relationships. Subunits are imagined to be "inlined" at their stub point, so
+subunits can be ignored for visibility purposes.
 
 The visibility rules for library units come from treating the
 environment declarative_part in the usual way, with one difference: In a
@@ -250,9 +250,9 @@
 
 The best way to introduce limited_with_clauses into this model is to say that
 there is an implicit declaration of a "limited view of package X" (occurring
-before any "limited with X"'s). The normal declaration of X then appears later
-in its usual place. "Limited with X" introduces a very limited view of X that
-only includes nested packages and incomplete types.
+before any instance of "limited with X"). The normal declaration of X then
+appears later in its usual place. The form "limited with X" introduces a very
+limited view of X that only includes nested packages and incomplete types.
 
 The changes to 10.1.2(8) ensure that, if for instance the specification of Q
 has a "with P.R", it shall not have a "limited with P" or a "limited with P.R".
@@ -260,7 +260,7 @@
 P.R.S" is fine.
 
 The fact that a "limited with P" hides the full view of P from all visibility
-prevents ripple effects. If you are is the scope of a "limited with P", the
+prevents ripple effects. If you are in the scope of a "limited with P", the
 full view of P is hidden from all visibility, even if P would otherwise be
 visible indirectly (e.g. by a renaming in an auxiliary package). So the
 limited_with_clause effectively reverts to the limited view of P, and the types
@@ -277,10 +277,10 @@
 using very simple syntactic analysis (we are lucky that it's possible to
 identify tagged types simply by looking at the syntax). But for package
 renamings and instantiations, the name of the renamed package or of the generic
-would need to be resolved, and that would required full-fledged visibility
+would need to be resolved, and that would require full-fledged visibility
 analysis.
 
-To simplify implementation and avoid funky Beaujolais effects, use clauses are
+To simplify implementation and avoid Beaujolais effects, use clauses are
 not allowed to mention a limited view of a package. Consider the example
 below; if the use clauses were legal, changing the "with A" to "with B" would
 silently change the meaning of X in P.C:
@@ -295,7 +295,7 @@
 
    limited with A;
    limited with B;
-   use A, B; -- Illegal, really.
+   use A, B; -- Illegal.
    package P is
    end P;
 
@@ -357,22 +357,21 @@
 use-visibility on some entity declared within its declarative region.
 
 A limited view of a package cannot be mentioned in a package renaming
-declaration. This restriction is probably not as critical as the others. The
-problem comes when someone from outside the unit containing the limited with
-references this package renaming. What does it see? If it has a "regular" with
-for the target of the limited-with, does it see the "full" view of the package
-via the renaming, or only the limited view of it. These are question that are
-best left unanswered.
+declaration. The problem comes when referencing such a renaming from a unit
+outside the unit containing the limited with. What view is seen? If the
+outside unit has a regular with clause for the target of the limited with, is
+the full view of the package visible via the renaming or only the limited view?
+These are questions that are best left unanswered.
 
 We do not allow a limited_with_clause to mention a procedure, because that
-would allow calling a procedure before its spec is elaborated. The language
-has no mechanism to deal with that. Similarly, we do not allow a
+would allow calling a procedure before its specification is elaborated. The
+language has no mechanism to deal with that. Similarly, we do not allow a
 limited_with_clause to mention a generic, because that would allow
-instantiating a generic before its spec is elaborated.
+instantiating a generic before its specification is elaborated.
 
 We do not allow a limited_with_clause to mention a generic instantiation or a
-renaming, because that would require all kinds of semantic analysis stuff, such
-as visibility.
+renaming, because that would require the full machinery of semantic analysis
+to determine the contents of the limited view (including visibility analysis).
 
 An implementation need not create the limited view of a unit if that unit is
 "really broken". For instance, the limited view of P may not be created if the
@@ -384,7 +383,7 @@
    end Bad;
 
 and even if the limited view is created, clients may still be rejected in an
-implementation defined manner. For the following unit might be rejected:
+implementation defined manner. Thus, the following unit might be rejected:
 
    limited with Bad;
    package Client is
@@ -396,13 +395,13 @@
 "inserted into the environment".
 
 The applicable nonlimited_ and limited_with_clauses determine (1) which
-entities are visible, (2) which dereferencing are legal and (3) what is the
+entities are visible, (2) which dereferencings are legal and (3) the
 type of dereferences. In particular:
 
 1 - Consider an expanded name P.X. X is visible if either the name is within
     the scope of a "with P" or if it is within the scope of a "limited with P"
-    and it is part of the limited view (if other words, it is a nested type or
-    package).
+    and it is part of the limited view (in other words, if it is a nested type
+    or package).
 
 2 - Consider a dereference X.all, where X is of an access-to-incomplete type
     with designated type T. This dereference is illegal unless it occurs in
@@ -421,9 +420,9 @@
 limited view, plus the normal package_declaration. Another option is to say
 that "the declaration of a library unit" is the normal package_declaration, the
 limited view being "something else". The latter option seems simpler, as it
-only requires to tweak 8.3(20) and doesn't interact with other parts of the
-language (e.g. freezing rules, library unit pragmas) like the former option
-would do.
+only requires the tweaking of 8.3(20) and doesn't interact with other parts of
+the language (e.g. freezing rules, library unit pragmas) like the former option
+would.
 
 The part about the "declarative region of the incomplete type" in the wording
 of 3.10.1(10) is intended to forbid a case like:
@@ -447,18 +446,18 @@
 of an incomplete type, so 3.10.1(10) would not apply; consequently, such a
 dereference would be legal even though it would be in the declarative region of
 the incomplete type T. Note that the final wording regarding dereferences will
-be provided by AI 326 based on the definition of partial views for incomplete
+be provided by AI-326 based on the definition of partial views for incomplete
 types.
 
-Presuming that AI 262 is adopted, limited_with_clauses also combine with
+Presuming that AI-262 is adopted, limited_with_clauses also combine with
 private_with_clauses, with the following syntax:
 
     limited private with P;
 
 Such a clause give visibility on the private view of P, but only at the
 beginning of the private part of the package where it appears. (The wording
-sections of AI 217 and AI 262 will obviously need to be merged when building
-the Draft International Standard.)
+sections of AI-217 and AI-262 will obviously need to be merged when building
+the Amendment.)
 
 !example
 
@@ -552,7 +551,7 @@
 @drepl
 A @i<package_>@fa<name> of a @fa<use_package_clause> shall denote a package.
 @dby
-A @i<package_>@fa<name> of a @fa<use_package_clause> shall denote a non-limited view of a
+A @i<package_>@fa<name> of a @fa<use_package_clause> shall denote a nonlimited view of a
 package.
 
 !corrigendum 8.4(7)
@@ -593,7 +592,7 @@
 @drepl
 The renamed entity shall be a package.
 @dby
-The renamed entity shall be a non-limited view of a package.
+The renamed entity shall be a nonlimited view of a package.
 
 
 !corrigendum 10.1.1(12)
@@ -628,8 +627,8 @@
 @i<not> the declaration of a library unit (the library package_declaration is);
 nonetheless, it is a @fa<library_item>.
 
-A library @fa<package_declaration> is the completion of its limited view
-declaration.
+A library @fa<package_declaration> is the completion of the declaration of
+its limited view.
 
 The elaboration of the limited view of a package has no effect.
 
@@ -3883,7 +3882,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.12 $ $Date: 2004/01/23 04:59:29 $
+          $Revision: 1.13 $ $Date: 2004/05/29 00:38:44 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -5692,7 +5691,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.12 $ $Date: 2004/01/23 04:59:29 $
+          $Revision: 1.13 $ $Date: 2004/05/29 00:38:44 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit

Questions? Ask the ACAA Technical Agent