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

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0342-1.txt

--- ai12s/ai12-0342-1.txt	2020/01/11 05:13:40	1.4
+++ ai12s/ai12-0342-1.txt	2020/01/14 05:15:44	1.5
@@ -1,4 +1,4 @@
-!standard 4.2.1(0)                                     20-01-10  AI12-0342-1/02
+!standard 4.2.1(0)                                     20-01-11  AI12-0342-1/03
 !standard 6.3.1(22)
 !reference AI12-0249-1
 !reference AI12-0295-1
@@ -44,11 +44,12 @@
 In 4.2.1(2/5), delete "nonoverridable, ".
 
 In 4.2.1(3/5, 4/5, and 5/5), replace (once in each)
-   "primitive function of T" with "function"
+   "that denotes a primitive function of T" with "that statically denotes a 
+    function"
 
 Append after 4.2.1 (5.a/5) (i.e., at the end of the Static Semantics section)
 
-   [AARM note:
+   AARM Ramification:
       Thus, the following example is legal because the preceding rules
       are name resolution rules (see 13.1.1):
          package Pkg1 is
@@ -57,11 +58,11 @@
             function Int_Lit (X, Y : T) return Duration; -- wrong profile
             function Int_Lit (Lit_Image : String) return T; -- right profile
          end;
-   end AARM note]
+   End AARM Ramification.
 
    These three aspects are inherited according to the rules given in 13.1.
 
-   [AARM Note:
+   AARM Discussion:
       This means that in this example
          package Pkg is
             type T1 is record
@@ -76,7 +77,7 @@
          end Pkg;
 
       the initial value of Pkg.X is (0,0), not (1,1).      
-   end AARM note]
+   End AARM Discussion.
 
    When a numeric literal is interpreted as value of a non-numeric
    type T or a string_literal is interpreted a value of a type T that
@@ -85,40 +86,45 @@
    Integer_Literal aspect for an integer literal, the Real_Literal aspect
    for a real literal, and the String_Literal aspect for a string_literal.
    The actual parameter of this notional call is a string literal
-   having the textual representation of the original (numeric or
-   string) literal.
+   having the textual representation of the original (numeric or string) 
+   literal.
 
-   Such a literal is said to be a "user-defined literal".
-
-   [AARM note:
+   AARM Discussion:
    This equivalence defines, for example, the nominal type, the nominal
    subtype, and the accessibility level of a user-defined literal.
    It also has the consequence that a user-defined literal shall not
    be of an abstract type (because that would be equivalent to a
    nondispatching call to an abstract function). This equivalence
-   also defines the dynamic semantics of evaluating a user-defined
-   literal.]
+   also defines the dynamic semantics of evaluating a user-defined literal.
 
+   The (sub)type of the actual parameter to this call is determined by the profile
+   of the appropriate aspect, and the bounds of the string literal are defined
+   by the usual rules for the bounds of a string literal.
+   End AARM Discussion.
+
+   Such a literal is said to be a "user-defined literal".
+
 Append after 4.2.1(6/5) (i.e., at the end of the Legality Rules section)
 
    If a nonabstract tagged type inherits any of these three aspects,
    then each inherited aspect shall be overridden.
-   
+ 
+Delete 4.2.1(7-8/5).
+   [This is the entire Dynamic Semantics section (it is now redundant).]
+
 Replace 6.3.1(22-22.a)
   - each primary that is a literal in one has the same value as the
     corresponding literal in the other. 
 
-  Ramification: The literals may be written differently.
+  AARM Ramification: The literals may be written differently.
 
 with
    - each primary that is a literal in one is a user-defined literal
      if and only if the corresponding literal in the other is also a
      user-defined literal. Furthermore, if neither are user-defined literals
-     then they shall have the same values [redundant , but they may have
+     then they shall have the same values Redundant[, but they may have
      differing textual representations]; if both are user-defined literals then
      they shall have the same textual representation.
-
-delete the entire Dynamic Semantics section (it is now redundant)
 
 !discussion
 

Questions? Ask the ACAA Technical Agent