CVS difference for ai12s/ai12-0220-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0220-1.txt

--- ai12s/ai12-0220-1.txt	2018/04/14 05:01:06	1.7
+++ ai12s/ai12-0220-1.txt	2018/04/27 03:51:14	1.8
@@ -1,4 +1,4 @@
-!standard 6.1.1(1/4)                                  18-04-05  AI12-0220-1/04
+!standard 6.1.1(1/4)                                  18-04-26  AI12-0220-1/05
 !standard 6.1.1(2/3)
 !standard 6.1.1(4/3)
 !standard 6.1.1(19/3)
@@ -21,8 +21,8 @@
 !problem
 
 In order to reason effectively about a subprogram call (perhaps in the context
-of a static analysis tool, perhaps not), more information is needed than just
-the parameter profile. That's why the Pre and Post were invented. But we still
+of a static analysis tool), more information is needed than just the parameter
+profile. That's why the Pre and Post aspects were invented. But we still
 need to know this sort of contract information even in the case where the
 callee is not known at compile time. In the case of dispatching calls, this
 need was recognized and Pre'Class and Post'Class were invented to meet this
@@ -39,7 +39,7 @@
 Modify 6.1.1(1/4):
 
 For a noninstance subprogram, a generic subprogram, [or ]an entry, {or an
-access-to-subrprogam type,} the following language-defined aspects may be
+access-to-subprogam type,} the following language-defined aspects may be
 specified with an aspect_specification (see 13.1.1):
 
 Modify 6.1.1(2/3):
@@ -49,8 +49,8 @@
 
 Add after AARM 6.1.1(3.a/3): 
 
-AARM Ramification: Pre'Class cannot be specified on access-to-subprogram type
-because of a Legality Rule found in 13.1.1 that limits 'Class aspects to
+AARM Ramification: Pre'Class cannot be specified on an access-to-subprogram
+type because of a Legality Rule found in 13.1.1 that limits 'Class aspects to
 tagged types and primitive subprograms of tagged types. The same is true for
 Post'Class (below).
 
@@ -109,7 +109,7 @@
   the conversion result; only the Pre and Post aspects of the target type
   of the conversion are relevant in that case. The same applies in the
   case of a "conversion" (using the term loosely) which is accomplished by
-  combining a dereference and a 'Access attribute reference, as in
+  combining a dereference and an Access attribute reference, as in
   Some_Pointer.all'Access.
 
 Modify 13.1.1(12/5):
@@ -146,7 +146,7 @@
 A call on Wrap will effectively enforce both (Some_Expr_B) (from the call to
 Wrap) and (Some_Expr_A) (from the call to P inside of Wrap). That's the same
 thing that is happening here. Indeed, one implementation strategy for this
-would be for each 'Access reference creating such a wrapper.
+would be for each 'Access reference to create such a wrapper.
 
 One can imagine static analysis tools (like SPARK) and style checking tools
 taking a different approach to 'Access references. By Ada not enforcing any

Questions? Ask the ACAA Technical Agent