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

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

--- ai12s/ai12-0249-1.txt	2018/11/28 07:25:13	1.3
+++ ai12s/ai12-0249-1.txt	2018/11/30 06:58:31	1.4
@@ -1,8 +1,9 @@
-!standard 4.2(5)                                     18-10-23  AI12-0249-1/02
-!standard 4.2(6)
+!standard 4.2(9)                                     18-11-29  AI12-0249-1/03
 !standard 4.2.1(0)
 !standard 4.9(3)
 !class Amendment 18-01-22
+!status Amendment 1-2012 18-11-29
+!status ARG Approved 10-0-0  18-10-22
 !status work item 18-01-22
 !status received 15-03-20
 !priority Low
@@ -16,33 +17,22 @@
 
 As we see an increasing interest in abstract data types such as
 containers, unbounded strings, "bignums," etc., the inability to use
-literals with these types becomes more evident.  In some cases, an
+literals with these types becomes more evident. In some cases, an
 operator such as unary "+" can be "hijacked" to provide for literals,
 but it always feels to be a bit of a kludge, and may require some kind
-of "use" clause for the operator to be visible.  Literals are currently
+of "use" clause for the operator to be visible. Literals are currently
 usable, for the types that support them, without "use" clauses, and it
 would be great if they could be used as easily with abstract data types
 as with certain special classes of types where they are now allowed.
 
 !proposal
 
-An aspect, or aspects, will be defined to allow a type to use numeric,
-string, character, and/or null literals.
+Aspects will be defined to allow a type to use numeric literals.
 
-String and character literals already rely on there being a single
-expected type, or a single expected profile, in the case of character
-literals (see RM 4.2).  Interestingly, you don't have to look "inside" a
-string or character literal until *after* you know its type.  Ada 83 had
-a different rule for character literals that relied on visibility of the
-declaration of the character literal, and current Ada has a different
-rule for X.'a', which also relies on visibility of the declaration.
-
-Numeric literals, and now the null literal as well, use a different
-overload resolution approach. They have a "universal" type, which then
-according to the overload resolution rules in RM 8.6, require the
-expected type to be a single type, as for string and character literals,
-or allow the expected type to be any type in a class, so long as the
-universal type of the literal "covers" the specified class.
+Numeric literals have a "universal" type, which then according to the 
+overload resolution rules in RM 8.6, require the expected type to be a 
+single type or allow the expected type to be any type in a class, so long 
+as the universal type of the literal "covers" the specified class.
 
 Since no types currently have Literal aspects, there is no immediate
 upward compatibility issue. However, if we decide to add Literal
@@ -50,12 +40,9 @@
 Unbounded_String), we will be potentially creating ambiguities.
 
 We need to decide how to represent the literals, and how to convert
-them. For character and string literals, we have Wide_Wide_Characters
-and Wide_Wide_Strings, so these represent "universal" representations
-which can accommodate any character set known in the universe. For
-numeric literals, we could choose a string representation, or some kind
-of Long_Long_Integer or Long_Long_Real. So long as all conversions of
-literals are propagated to a library-unit elaboration procedure for
+them. For numeric literals, we could choose a string representation, or 
+some kind of Long_Long_Integer or Long_Long_Real. So long as all conversions 
+of literals are propagated to a library-unit elaboration procedure for
 library-level types, and to the point of declaration of the type for
 nested types, the overhead of converting literals can be kept
 manageable. One might often hope the conversion routines could be
@@ -77,81 +64,15 @@
 
 !wording
 
-Modify paragraph 3.5.2(1):
-
-   An enumeration type is said to be a /character/ type if at least one of
-   its enumeration literals is a character_literal{, as is a type with a
-   specified Character_Literal aspect (see 4.2.1)}.
-
-Modify paragraph 3.6.3(1):
-
-   A one-dimensional array type whose component type is a character type
-   is called a /string/ type{, as is a type with a specified String_Literal
-   aspect (see 4.2.1)}.
-
-Modify paragraph 4.2(3):
-
- For a name that consists of a character_literal, either{:
-  *}its expected type shall be a single character type {T}, in which
-    case it is interpreted as {follows:
-    * if T is an enumeration type, as} a parameterless function_call
-      that yields the corresponding value of the character type[,]{;
-    * if T has a Character_Literal aspect specified (see 4.2.1), as a
-      function_call on the named function that yields the corresponding
-      value of the character type;
-  *}or its expected profile shall correspond to a parameterless
-    function with a character result type, in which case it is interpreted
-    as the name of the corresponding parameterless function declared as
-    part of the character type's definition (see 3.5.1). In either case,
-    the character_literal denotes the enumeration_literal_specification.
-
-
-Modify paragraph 4.2(5):
-
- {For a character_literal that is a name, if the expected type for the
- literal is an enumeration type or if there is an expected profile, the}
- [A]character_literal [that is a name] shall correspond to a
- defining_character_literal of the expected type, or of the result type
- of the expected profile.
-
-Modify paragraph 4.2(6)
- {If the expected type for a string_literal is a one-dimensional
- array type with a component type that is an enumeration type, then}
- [F]{f}or each character of [a]{the} string_literal [with a given
- expected string type,] there shall be a corresponding
- defining_character_literal of the [component type of the expected
- string type]{enumeration type}.
-
 Modify paragraph 4.2(9):
 
- {If its expected type is a numeric type, t}[T]he evaluation of a
+ {If its expected type is a numeric type, the}[The] evaluation of a
  numeric literal[, or the literal null,] yields the represented value.
- {If its expected type is an access type, the evaluation of the literal
- null yields the null value of the expected type. In other cases,
- the effect of evaluating a numeric or null literal is determined by the
- Integer_Literal, Real_Literal, or Null_Literal aspect that applies
- (see 4.2.1).}
+ The evaluation of the literal null yields the null value of the 
+ expected type. In other cases, the effect of evaluating a numeric
+ literal is determined by the Integer_Literal or Real_Literal aspect 
+ that applies (see 4.2.1).
 
-Modify paragraph 4.2(10):
- The evaluation of a string_literal that is a primary {and has an
- expected type that is a one-dimensional array type with a character
- type as its component type,} yields an array value containing the value
- of each character of the sequence of characters of the string_literal,
- as defined in 2.6. The bounds of this array value are determined
- according to the rules for positional_array_aggregates (see 4.3.3),
- except that for a null string literal, the upper bound is the
- predecessor of the lower bound.
-
-Modify paragraph 4.2(11):
- For the evaluation of a string_literal of type T, {if its expected type
- is a one-dimensional array type with a component subtype that is a
- constrained subtype of a character type,} a check is made that the
- value of each character of the string_literal belongs to the component
- subtype of T. For the evaluation of a null string literal, a check is
- made that its lower bound is greater than the lower bound of the base
- range of the index type. The exception Constraint_Error is raised if
- either of these checks fails.
-
 Add subclause 4.2.1 User-Defined Literals
 
 Using one or more of the aspects defined below, a type may be specified
@@ -172,47 +93,10 @@
     primitive function of T with one parameter of type String and a
     result type of T.
 
-The following nonoverridable, type-related operational aspect may be
-specified for a type T:
-
-  Null_Literal
-    This aspect is specified by a name that denotes a constant object of
-    type T, or that denotes a primitive function of T with no parameters
-    and a result type of T.
-
-The following nonoverridable, type-related operational aspect may be
-specified for a type T:
-
-  String_Literal
-    This aspect is specified by a /function_/name that denotes a
-    primitive function of T with one parameter of type
-    Wide_Wide_String and a result type of T.
-
-  [Redundant: A type with a specified String_Literal aspect is considered a
-  /string/ type.]
-
-The following nonoverridable, type-related operational aspect may be
-specified for a type T other than an enumeration type:
-
-  Character_Literal
-    This aspect is specified by a /function_/name that denotes a
-    primitive function of T with one parameter of type
-    Wide_Wide_Character and a result type of T.
-
-  [Redundant: A type with a specified Character_Literal aspect is
-  considered a
-  /character/ type.]
-
   Legality Rules
 
 The Integer_Literal or Real_Literal aspect shall not be specified for a
-type T if the full view of T is a numeric type. The Null_Literal aspect
-shall not be specified for a type T if the full view of T is an access
-type. The Character_Literal aspect shall not be specified for a type T
-if the full view of T is a character type (in the absence of the
-Character_Literal aspect specification). The String_Literal aspect shall
-not be specified for a type T if the full view of T is a string type (in
-the absence of the String_Literal aspect specification). In addition to
+type T if the full view of T is a numeric type. In addition to
 the places where Legality Rules normally apply (see 12.3), these rules
 also apply in the private part of an instance of a generic unit.
 
@@ -224,33 +108,6 @@
 the parameter being a string with lower bound one whose value corresponds
 to the textual representation of the integer (or real) literal.
 
-For the evaluation of a null literal with expected type having a
-Null_Literal aspect specified, the value is the that of the constant
-object denoted by the aspect, or the result of a call on the
-parameterless function denoted by the aspect.
-
-For the evaluation of a character_literal with expected type having a
-Character_Literal aspect specified, the value is the result of a call on
-the function specified by the aspect, with the parameter being the
-Wide_Wide_Character that corresponds to the literal.
-
-For the evaluation of a string_literal with expected type having a
-String_Literal aspect specified, the value is the result of a call on
-the function specified by the aspect, with the parameter being the
-Wide_Wide_String with lower bound one that corresponds to the literal.
-
-  Implementation Permissions
-
-For a literal with an expected type having a corresponding _Literal
-aspect specified to denote a function that has a Global aspect that
-indicates that there are no references to global variables, the
-implementation is permitted to evaluate the literal at compile time, or
-at run time at any point after the freezing point of the expected type,
-and prior to the first use of the value of the literal. Furthermore, if
-two such literals with the same expected type have identical textual
-representations, the result of evaluating one of the literals may be
-used as the value for both literals.
-
   Bounded Errors
 
 It is a bounded error if the evaluation of a literal with expected type
@@ -259,6 +116,29 @@
 run time, or Program_Error or the exception propagated by the evaluation
 is raised at the point of use of the value of the literal.
 
+AARM Implementation Note:
+As always, an implementation may apply "as-if" optimizations (those that
+result in the same external effects in the absence of erroneous execution) to 
+the function calls associated with user-defined literals. In particular,
+if the function associated with a _Literal aspect has a Global aspect that
+indicates no references to global variables, then a number of optimizations
+are available to the implementation:
+* The implementation can evaluate a user-defined literal function at 
+  compile-time if it has access to the body of the function (for example, 
+  if it is inlined), and that body doesn't reference anything
+  evaluated at runtime. If the compile-time evaluation results in an exception,
+  this bounded error allows the compilation unit to be rejected.
+* Implementations can use existing permissions (see 6.1.2) to 
+  avoid evaluating the function associated with a user-defined literal
+  more than once for a particular literal value. This evaluation can be
+  "hoisted" (done once per compilation unit during the elaboration of the
+  unit) if the compiler can prove that the function doesn't depend on any
+  constants or locals with a runtime value not yet elaborated.
+* If the literal value is not needed by the execution of the program,
+  the function call can be omitted even if it might have side-effects
+  (again, see 6.1.2).
+
+
 Modify 4.9(3) and the following AARM note:
 
   * a numeric_literal {of a numeric type};
@@ -290,16 +170,13 @@
 
 * More generally, we chose to allow user-defined literals on almost
   any sort of type, so long as that sort of type didn't already allow
-  that sort of literal.  The thought was that you could imagine a
+  that sort of literal. The thought was that you could imagine a
   floating point type that would allow the use of string literals
-  for certain special values like "NaN" or "+inf".  Or an integer type
-  that would allow character literals, which would be interpreted
-  as their 16-bit Unicode value, say -- the "signed_char" and
-  "unsigned_char" types in Interfaces.C come to mind.
+  for certain special values like "NaN" or "+inf".
 
   For the purposes of this rule, we treated all numeric literals
   as one "kind" of literal, and disallow any numeric type from having
-  user-defined numeric literals.  Having the presence or absence of
+  user-defined numeric literals. Having the presence or absence of
   a "." seemed too subtle to trigger a completely different effect
   when the expected type was a numeric type.
 
@@ -310,20 +187,6 @@
 
 !examples
 
-   type Varying_String is private
-     with String_Literal => To_Varying_String;
-
-   function To_Varying_String (Source : Wide_Wide_String)
-     return Varying_String;
-
-   ...
-
-   X : constant Varying_String := "This is a test";
-     --  Equivalent to:
-     --  X : constant Varying_String :=
-     --        To_Varying_String
-     --           (Wide_Wide_String'("This is a test"));
-
    type Big_Integer is private
      with Integer_Literal => Big_Integer_Value;
 
@@ -336,6 +199,71 @@
      --  Equivalent to:
      --    Y : Big_Integer := - Big_Integer_Value ("3");
 
+!corrigendum 4.2(9)
+
+@drepl
+The evaluation of a numeric literal, or the literal @b<null>,
+yields the represented value.
+@dby
+If its expected type is a numeric type, the evaluation of a
+numeric literal yields the represented value.
+The evaluation of the literal @b<null> yields the null value of the 
+expected type. In other cases, the effect of evaluating a numeric
+literal is determined by the Integer_Literal or Real_Literal aspect 
+that applies (see 4.2.1).
+
+!corrigendum 4.2.1(0)
+
+@dinsc
+
+Using one or more of the aspects defined below, a type may be specified
+to allow the use of one or more kinds of literals as values of the type.
+
+@s8<@i<Static Semantics>>
+
+The following nonoverridable, type-related operational aspects may be
+specified for any type @i<T>:
+
+@xhang<@xterm<Integer_Literal>
+This aspect is specified by a @i<function_>@fa<name> that denotes a
+primitive function of @i<T> with one parameter of type String and a
+result type of @i<T>.>
+
+@xhang<@xterm<Real_Literal>
+This aspect is specified by a @i<function_>@fa<name> that denotes a
+primitive function of @i<T> with one parameter of type String and a
+result type of @i<T>.>
+
+@s8<@i<Legality Rules>>
+
+The Integer_Literal or Real_Literal aspect shall not be specified for a
+type T if the full view of T is a numeric type. In addition to
+the places where Legality Rules normally apply (see 12.3), these rules
+also apply in the private part of an instance of a generic unit.
+
+@s8<@i<Dynamic Semantics>>
+
+For the evaluation of an integer (or real) literal with expected type
+having an Integer_Literal (or Real_Literal) aspect specified, the value
+is the result of a call on the function specified by the aspect, with
+the parameter being a string with lower bound one whose value corresponds
+to the textual representation of the integer (or real) literal.
+
+@s8<@i<Bounded Errors>>
+
+It is a bounded error if the evaluation of a literal with expected type
+having a corresponding _Literal aspect specified, propagates an
+exception. The possible effect is that an error is reported prior to
+run time, or Program_Error or the exception propagated by the evaluation
+is raised at the point of use of the value of the literal.
+
+!corrigendum 4.9(3)
+
+@drepl
+@xbullet<a @fa<numeric_literal>;>
+@dby
+@xbullet<a @fa<numeric_literal> of a numeric type;>
+
 !ASIS
 
 [Not sure. Might need new aspect names, but I didn't check - Editor.]
@@ -1437,5 +1365,149 @@
 Tucker had replied that "he was convinced", but the permission remains. We 
 actually discussed it a bit during the meeting, so I don't want to delete it
 without getting the OK from this list.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, November 28, 2018  10:33 AM
+
+> Pushed send too soon.
+> 
+> (7) In discussion, we had agreed that we needed to define the bounds 
+> of the string passed to these routines (for numeric and string 
+> literals). There doesn't seem to be any reason to get fancy here, so I 
+> just added that the lower bound of that string is one (the upper bound 
+> then is obvious without needing discussion).
+> 
+> Specifically:
+> 
+> For the evaluation of an integer (or real) literal with expected type 
+> having an Integer_Literal (or Real_Literal) aspect specified, the 
+> value is the result of a call on the function specified by the aspect, 
+> with the parameter being a string with lower bound one whose value 
+> corresponds to the textual representation of the integer (or real) literal.
+> 
+> and
+> 
+> For the evaluation of a string_literal with expected type having a 
+> String_Literal aspect specified, the value is the result of a call on 
+> the function specified by the aspect, with the parameter being the 
+> Wide_Wide_String with lower bound one that corresponds to the literal.
+
+The above seems fine.
+
+> (8) For the string literal case, the wording defines such types as 
+> "string types". I had wondered:
+> 
+>> Umm, don't "string types" have a bunch of extra semantics beyond just 
+>> literals? In particular, string types can be static. Doesn't this 
+>> cause some problems?
+> 
+> to which Tucker responded:
+> 
+> "Good point, we will have to look at that."
+> 
+> But so far as I can tell, no one has. Hopefully someone will do that ASAP.
+
+"string type" appears in the following places in the RM:
+
+3.6.3 String Types -- whole section
+4.2 Literals -- many paragraphs
+4.9 Static Expressions and Static Subtypes -- para 26/3
+
+4.2 and 3.6.3 are already handled in this AI.
+
+4.9(26/3) should be modified as follows:
+
+A static subtype is either a static scalar subtype or a static string subtype.
+A static scalar subtype is an unconstrained scalar subtype whose type is not a
+descendant of a formal type, or a constrained scalar subtype formed by
+imposing a compatible static constraint on a static scalar subtype. A static 
+string subtype is {a string subtype that does not have a specified 
+String_Literal aspect, and that is} an unconstrained [string]{array} subtype 
+whose index subtype and component subtype are static, or a constrained 
+[string]{array} subtype formed by imposing a compatible static constraint on
+a static string subtype. In any case, the subtype of a generic formal object
+of mode in out, and the result subtype of a generic formal function, are not
+static. Also, a subtype is not static if any Dynamic_Predicate specifications
+apply to it. 
+
+> (9) I had suggested eliminating the Implementation Permission 
+> completely (replacing it with an Implementation Note suggesting the 
+> use of as-if optimizations and applying the permission to call a 
+> function with Global => null only once), since it doesn't allow 
+> anything that isn't already allowed for any Global => null function. 
+> (At least, I've been assuming that there is a rule similar to the one 
+> for functions in Pure packages that applies to such functions -- they 
+> have similar purposes -- if not, we should fix AI12-0079-1, not this 
+> AI!)
+> 
+> Tucker had replied that "he was convinced", but the permission 
+> remains. We actually discussed it a bit during the meeting, so I don't 
+> want to delete it without getting the OK from this list.
+
+I am OK with your suggestion.  Let me know if you would like some proposed 
+wording for this Implementation Note (or Advice?).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 29, 2018  8:41 PM
+
+...
+> > (9) I had suggested eliminating the Implementation Permission 
+> > completely (replacing it with an Implementation Note suggesting the 
+> > use of as-if optimizations and applying the permission to call a 
+> > function with Global => null only once), since it doesn't allow 
+> > anything that isn't already allowed for any Global => null function. 
+> > (At least, I've been assuming that there is a rule similar to the 
+> > one for functions in Pure packages that applies to such functions -- 
+> > they have similar purposes -- if not, we should fix AI12-0079-1, not 
+> > this AI!)
+> > 
+> > Tucker had replied that "he was convinced", but the permission 
+> > remains. We actually discussed it a bit during the meeting, so I 
+> > don't want to delete it without getting the OK from this list.
+> 
+> I am OK with your suggestion.  Let me know if you would like some 
+> proposed wording for this Implementation Note (or Advice?).
+
+I don't think Implementation Advice is needed here, as I have yet to meet 
+an implementer who wants to generate worse code than they need to based on
+the language definition. ;-)
+
+Here is the Implementation Note that I put after the Bounded Error in the 
+original AI (after deleting the permission):
+
+AARM Implementation Note:
+As always, an implementation may apply "as-if" optimizations (those that 
+result in the same external effects in the absence of erroneous execution) 
+to the function calls associated with user-defined literals. In particular, 
+if the function associated with a _Literal aspect has a Global aspect that 
+indicates no references to global variables, then a number of optimizations
+are available to the implementation:
+
+* The implementation can evaluate a user-defined literal function at
+  compile-time if it has access to the body of the function (for example,
+  if it is inlined), and that body doesn't reference anything
+  evaluated at runtime. If the compile-time evaluation results in an exception,
+  this bounded error allows the compilation unit to be rejected.
+
+* Implementations can use existing permissions (see 6.1.2) to
+  avoid evaluating the function associated with a user-defined literal
+  more than once for a particular literal value. This evaluation can be
+  "hoisted" (done once per compilation unit during the elaboration of the
+  unit) if the compiler can prove that the function doesn't depend on any
+  constants or locals with a runtime value not yet elaborated.
+
+* If the literal value is not needed by the execution of the program,
+  the function call can be omitted even if it might have side-effects
+  (again, see 6.1.2).
+
+
+P.S. In case you're not up to speed on everything, "6.1.2" is the subclause 
+added by AI12-0079-1. Tucker and I have been discussing off-line the 
+permission that is currently missing from that AI. Much more on that when 
+we discuss that AI again, most likely at our upcoming meeting.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent