CVS difference for ais/ai-20218.txt

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

--- ais/ai-20218.txt	2003/10/29 00:42:07	1.8
+++ ais/ai-20218.txt	2003/12/07 05:00:34	1.9
@@ -1,4 +1,4 @@
-!standard 8.3(26)                                    03-10-21  AI95-00218-03/03
+!standard 8.3(26)                                    03-12-03  AI95-00218-03/04
 !standard 2.9(3)
 !standard 6.1(2)
 !standard 6.1(3)
@@ -94,7 +94,7 @@
 
 The general idea is that subprogram declarations that are overriding are
 prefixed with "overriding", whereas subprogram declarations that are prefixed
-"not overriding" must not override another routine. The same applies to
+with "not overriding" must not override another routine. The same applies to
 subprogram bodies, renamings, and generic instantiations.
 
 If no prefix is given, the Ada 95 rules are used. This has the effect of
@@ -139,10 +139,10 @@
 subprogram_renaming_declaration, or generic_instantiation of a subprogram has an
 overriding_indicator, then:
   * the operation shall be a primitive operation for some type;
-  * if the overriding_indicator is "overriding", then it shall override
-    another homograph at the point of the declaration or body;
-  * if the overriding_indicator is "not overriding", then it shall not override
-    another homograph (at any point).
+  * if the overriding_indicator is "overriding", then the operation shall
+    override a homograph at the point of the declaration or body;
+  * if the overriding_indicator is "not overriding", then the operation shall
+    not override any homograph (at any point).
 In addition to the places where Legality Rules normally apply, these rules also
 apply in the private part of an instance of a generic unit.
 
@@ -177,7 +177,7 @@
 
 !example
 
-Here is our original example using the new and syntax.
+Here is our original example using the new syntax.
 
 with Root;
 package Leaf is
@@ -200,7 +200,7 @@
 This is because we do not want them to be permitted in all syntactic situations
 which use subprogram specification such as generic subprogram declarations,
 formal subprogram parameters and subprogram body stubs. However, we do want
-them to apply to abstract subprograms, to bodies, to renaming and to generic
+them to apply to abstract subprograms, to bodies, to renamings and to generic
 instantiations. For example
 
    overriding
@@ -233,30 +233,30 @@
 
 
 An important principle is that an overriding_indicator never 'lie' to the user.
-That is, it should never be the case that an operation is marked 'overriding'
-when it is not, nor should be marked 'not overriding' when it is.
+That is, it should never be the case that an operation is marked "overriding"
+when it is not, nor should it be marked "not overriding" when it is.
 
 This matters when private types are brought into the picture.
 
-Presume type T2 has an operation Foo, but its parent type T1 does not. Then
+Assume type T2 has an operation Foo, but its parent type T1 does not. Then
 
 package P is
    type T is new T1 with private;
-   procedure Foo; -- Can't give 'overriding' here.
+   procedure Foo (Obj : in out T); -- Can't give "overriding" here.
 private
    type T is new T2 with ...;
 end P;
 
-We don't allow giving 'overriding' on Foo, as it is not an overriding
+We don't allow giving "overriding" on Foo, as it is not an overriding
 operation of the partial view. To a user looking at the package from outside
 without seeing the private part, there is no Foo to override from. So, allowing
 the code to say otherwise would be confusing.
 
-On the other hand, we don't allow giving 'not overriding' on Foo, either. That
+On the other hand, we don't allow giving "not overriding" on Foo, either. That
 would be a worse lie, as the routine eventually will become overriding when
 the full declaration is given.
 
-The indicator 'overriding' can be given on the subprogram_body, if desired.
+The indicator "overriding" can be given on the subprogram_body, if desired.
 
 If T1 does have the operation Foo, then an overriding indicator can (and
 should) be given for the partial view. Thus
@@ -264,15 +264,15 @@
 package P is
    type T is new T1 with private;
    overriding
-   procedure Foo;      -- partial view is overriding
+   procedure Foo (Obj : in out T); -- Partial view is overriding
 private
    type T is new T2 with ...;
 end P;
 
 Later overriding can occur not just in the private part, but at various other
 locations as well (because of the rules of 7.3.1(6)). This later overriding
-is ignored when checking 'overriding' (because otherwise the declaration
-would lie), but is taken into account when checking 'not overriding' (again
+is ignored when checking "overriding" (because otherwise the declaration
+would lie), but is taken into account when checking "not overriding" (again
 to prevent lying).
 
 An example of how this could happen:
@@ -316,7 +316,7 @@
 so no earlier overriding_indicator could be supported. Examples like these
 are a second reason that overriding_indicators are allowed on bodies.
 
-Some drafts of this AI supported a separate clause to allow giving the
+Some drafts of this AI supported a distinct clause to allow giving the
 overriding_indicator at the point where the overriding actually occurred.
 This clause doesn't seem necessary. For tagged types, it would only be needed
 in cases (like the first one) where we wish to make the same operations visible
@@ -348,7 +348,7 @@
 
 Giving an overriding_indicator in this way is illegal. This avoids an
 "implicit contract" that GT have an Op. However, we still have an
-implicit contract when not overriding is used. Consider:
+implicit contract when "not overriding" is used. Consider:
 
 generic
     type GT is tagged private;
@@ -364,13 +364,14 @@
 Legality Rules are rechecked in the instance, an instantiation of Gen2 would
 be illegal if GT in fact had an Op primitive subprogram.
 
-Because of this strange asymetrical result, we also considered two other rules:
-  1) The standard 12.3(11) rule (with checking in the private part of the instance);
+Because of this strange asymmetrical result, we also considered two other rules:
+  1) The standard 12.3(11) rule (with checking in the private part of the
+     instance);
   2) As (1), except that no checking is done in the generic_declaration;
   3) As (1), except that no checking is done in the instance.
 
-(1) does not require rechecking of 'overriding' in the instance (it cannot
-fail), while it does require checking of 'not overriding' in both the
+(1) does not require rechecking of "overriding" in the instance (it cannot
+fail), while it does require checking of "not overriding" in both the
 declaration and instance. (2) and (3) does not require rechecking (each check
 is made only once).
 
@@ -391,7 +392,7 @@
 
 Deciding between (1) and (2) is hard. (2) allows "implicit contracts" for both
 "not overriding" and "overriding", and thus makes their behavior more
-symetrical. If (2) was adopted, the original example:
+symmetrical. If (2) was adopted, the original example is now legal:
 
 generic
     type GT is tagged private;
@@ -403,8 +404,7 @@
     -- ...
 end Gen;
 
-This would be legal if (2) is adopted. The effect would be to force
-all actual types for GT to have an operation Op.
+The effect would be to force all actual types for GT to have an operation Op.
 
 While this looks appealing from a consistency standpoint, it is questionable
 how useful it is. Therefore, we have adopted the standard Ada rule (which
@@ -426,10 +426,10 @@
 
 If the type T has Op as an operation then there is not an added contract (all
 possible types will have Op). However, if T does not have Op as a primitive,
-the generic unit is ileggal.
+the generic unit is illegal.
 
 
-Overriding_Indicators are allowed on all types. We cannot restrict them to
+Overriding_indicators are allowed on all types. We cannot restrict them to
 just tagged types, because doing so would lead to contract model problems.
 While the primary use for this feature is with tagged types, we do need to
 insure that untagged types do not cause problems.
@@ -456,7 +456,7 @@
 occurs or not - nor should it since either implementation ought to be
 acceptable. We should therefore remain silent regarding overriding in the
 partial view. This is similar to the private extension case discussed
-earlier. 'Overriding' would be illegal on both examples, while 'Not overriding'
+earlier. "Overriding" would be illegal on both examples, while "not overriding"
 would be allowed only on the second one (which would constrain the
 implementation). Again, it is permissible to put an overriding_indicator
 on the body of "+" to indicate whether or not it is an overriding routine.
@@ -515,12 +515,12 @@
 However, while this seems appealing at first glance, there are a number of
 issues:
 1) The check has to be delayed until the end of the compilation of the body,
-as a overriding_indicator may be seen on the body.
+as an overriding_indicator may be seen on the body.
 2) Restrictions apply inside of generic units. However, many generic units
 will prefer to avoid implicit contracts by avoiding the use of
 overriding_indicators. Moreover, there are examples where no indicator can
 be given (as shown above).
-3) This rules apply to all primitive operations, including untagged ones.
+3) These rules apply to all primitive operations, including untagged ones.
 The value of overriding indicators is much less for untagged types, and
 giving them for all operators could be a burden.
 4) Restrictions are generally partition-wide, and many compilers do not
@@ -530,7 +530,7 @@
 
 While solutions can be found for all of these problems, it doesn't seem likely
 that a one-size-fits-all solution can be found (particularly for the generic
-issues). Moreover, the greatest value to this proposal is simply allowing the
+issues). Moreover, the greatest value of this proposal is simply allowing the
 programmer to declare overriding routines (and getting an error if that
 intent is not followed). The vast majority of problems of this sort are
 cases where Finalize or another overridden routine is not called when the
@@ -558,7 +558,7 @@
 overriding for a body. Generally, similar pragmas (like Inline) are not
 allowed on bodies. Putting the pragma inside the body would be weird;
 putting it before it would violate the normal rules for pragmas.
-Putting the pragma after the body would separate it a long ways from the
+Putting the pragma after the body would separate it a long way from the
 specification that it applied to.
 
 We considered an alternative that allowed the pragmas to appear anywhere.
@@ -567,7 +567,7 @@
 needed. Two options were considered:
 
 * Giving the full profile of the subprogram in the pragma. This can be
-  done as was done in the DEC VAX pragmas (which is ugly, and do not handle
+  done as was done in the DEC VAX pragmas (which is ugly, and does not handle
   access parameters cleanly), or by adding syntax to allow a profile in
   a pragma (which is more complex than the syntax change proposed).
 * Giving the pragmas a scope of application:
@@ -577,18 +577,16 @@
     procedure Add (O : in out T; S: String);
     procedure Add (O : in out T; F: Float);
   However, this constrains the order of declarations, and makes it much more
-  likely that the pragma would be missed. Consider would would happen if the
+  likely that the pragma would be missed. Consider what would happen if the
   Float version of Add were moved to the top without the pragma. Keep in mind
-  that in real programs that these aren't one line subprogram declarations,
+  that in real programs, these aren't one line subprogram declarations,
   but routines with 5 parameters and 20 lines of comments. A far-away pragma
-  could get lost. Moreover, we still need the ability to redeclare primitives,
-  which is new syntax (well, at least a new use for existing syntax which will
-  have quite an impact on syntax-directed compilers).
+  could get lost.
 
 An important goal of this amendment is that new features are cleanly integrated
 into the language; they shouldn't look "bolted-on". This feature will be used
 quite frequently in Ada programs; pragmas start out looking ugly and wordy and
-it seems unlikely that the passage of time will improve that.
+it seems unlikely that the passage of time would improve that.
 
 We also considered various other forms of syntax where the indicator
 followed the details of the subprogram such as
@@ -603,11 +601,11 @@
 the need to indicate not overriding as well. Placing the indicator at
 the front has the merit of being uniform and easily seen by the reader.
 
-The keyword "overriding" seems natural but the use of "not overriding" is
-not as clear. The problem with "not overriding" is that it is rather similar
-to the opposite meaning. However, other obvious choices (like "overloading" or
-"overloaded") suffer from the same problem, and no programmer is likely to
-mistake the meaning of "not".
+The keyword "overriding" seems natural but the use of "not overriding" is not
+as clear. The problem with "not overriding" is that it is not very different
+from "overriding", which has the opposite meaning. However, other obvious
+choices (like "overloading" or "overloaded") suffer from the same problem, and
+no programmer is likely to mistake the meaning of "not".
 
 !corrigendum 2.9(03)
 
@@ -687,10 +685,10 @@
 @fa<generic_instantiation> of a subprogram has an
 @fa<overriding_indicator>, then:
 @xbullet<the operation shall be a primitive operation for some type;>
-@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then it shall
-override another homograph at the point of the declaration or body;>
-@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then it shall
-not override another homograph (at any point).>
+@xbullet<if the @fa<overriding_indicator> is @b<overriding>, then the operation
+shall override a homograph at the point of the declaration or body;>
+@xbullet<if the @fa<overriding_indicator> is @b<not overriding>, then the
+operation shall not override any homograph (at any point).>
 In addition to the places where Legality Rules normally apply, these rules also
 apply in the private part of an instance of a generic unit.
 
@@ -718,7 +716,7 @@
         @b<new> @i<generic_package_>>@fa<name [generic_actual_part];
    | [overriding_indicator] >@ft<@b<procedure>>@fa< defining_program_unit_name >@ft<@b<is>
         @b<new> @i<generic_procedure_>>@fa<name [generic_actual_part];
-   | [overriding_indicator]>@ft<@b<function>>@fa< defining_designator >@ft<@b<is>
+   | [overriding_indicator] >@ft<@b<function>>@fa< defining_designator >@ft<@b<is>
         <@b<new> @i<generic_function_>>@fa<name [generic_actual_part];>>
 
 !ACATS test

Questions? Ask the ACAA Technical Agent