CVS difference for ai12s/ai12-0249-1.txt
--- ai12s/ai12-0249-1.txt 2018/01/25 07:32:08 1.2
+++ ai12s/ai12-0249-1.txt 2018/11/28 07:25:13 1.3
@@ -1,6 +1,7 @@
-!standard 4.2(5) 18-01-22 AI12-0249-1/01
+!standard 4.2(5) 18-10-23 AI12-0249-1/02
!standard 4.2(6)
!standard 4.2.1(0)
+!standard 4.9(3)
!class Amendment 18-01-22
!status work item 18-01-22
!status received 15-03-20
@@ -9,7 +10,7 @@
!subject User-defined literals
!summary
-** TBD.
+A mechanism for user-defined literals is added.
!problem
@@ -44,34 +45,33 @@
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
+upward compatibility issue. However, if we decide to add Literal
aspects to any existing language-defined types (such as
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
+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
+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
+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
+manageable. One might often hope the conversion routines could be
evaluated statically, but clearly we are getting into compiler-specific
optimizations.
Because one use for numeric literals would be for extended precision
types, it seems wiser to represent a numeric literal as a string, and
require the type to provide a conversion function from string to the
-type. As mentioned above, the overhead of conversion can hopefully be
+type. As mentioned above, the overhead of conversion can hopefully be
reduced by having the compiler "hoist" the literals to a point where the
conversions are only performed at most once at run-time, and ideally at
-compile or link time. Because the conversion might fail, we need to
+compile or link time. Because the conversion might fail, we need to
specify that it is a bounded error if a literal conversion function
propagates an exception, with consequences being a compile-time or
-link-time error, or a Program_Error propagated prior to the point where
-the value of the literal is used, or the exception propagated by the
+link-time error, or a Program_Error or the exception propagated by the
conversion function, raised at the point where the value of the literal
is used.
@@ -127,10 +127,10 @@
{If its expected type is a numeric type, t}[T]he 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,
+ 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).
+ (see 4.2.1).}
Modify paragraph 4.2(10):
The evaluation of a string_literal that is a primary {and has an
@@ -138,7 +138,7 @@
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 ),
+ 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.
@@ -152,7 +152,7 @@
range of the index type. The exception Constraint_Error is raised if
either of these checks fails.
-Add section 4.2.1 User-Defined Literals
+Add subclause 4.2.1 User-Defined Literals
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.
@@ -160,7 +160,7 @@
Static Semantics
The following nonoverridable, type-related operational aspects may be
-specified for a type T other than a numeric type:
+specified for any type T:
Integer_Literal
This aspect is specified by a /function_/name that denotes a
@@ -173,7 +173,7 @@
result type of T.
The following nonoverridable, type-related operational aspect may be
-specified for a type T other than an access type:
+specified for a type T:
Null_Literal
This aspect is specified by a name that denotes a constant object of
@@ -181,8 +181,7 @@
and a result type of T.
The following nonoverridable, type-related operational aspect may be
-specified for a type T, unless T is a one-dimensional array type whose
-component type is a character type:
+specified for a type T:
String_Literal
This aspect is specified by a /function_/name that denotes a
@@ -204,14 +203,26 @@
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
+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.
+
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 whose value corresponds to the textual
-representation of the integer (or real) literal.
+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
@@ -226,27 +237,39 @@
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 that corresponds to the literal.
+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, 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.
+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
having a corresponding _Literal aspect specified, propagates an
-exception. The possible effect is that an error is reported prior to
-run time, Program_Error is raised at some point prior to any use of
-the value of the literal, or the exception propagated by the evaluation
+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.
+Modify 4.9(3) and the following AARM note:
+
+ * a numeric_literal {of a numeric type};
+
+ AARM Ramification: A numeric_literal {of a numeric type} is always a
+ static expression, even if its expected type is not that of a static
+ subtype. However, if its value is explicitly converted to, or
+ qualified by, a nonstatic subtype, the resulting expression is
+ nonstatic. {Non-numeric types can have numeric literals if aspect
+ Integer_Literal or Real_Literal is used; these are never static.}
+
!discussion
The !proposal section includes a relatively complete discussion of the
@@ -258,9 +281,12 @@
used the type's "-" operator, while a type supporting user-defined
literals bypassed the "-" operator.
-* A literal may be usable on a partial view but not on the full view,
- if the full view is a type that already has meaning for the same
- sort of literal. That seems OK.
+* We do not want to have a situation where a literal may be usable on a
+ partial view but not on the full view, for example, because the full
+ view is a type that already has meaning for the same sort of literal.
+ This avoids problems with full conformance checking when the meaning
+ of a literal might be different in the visible and private parts of a
+ package.
* 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
@@ -276,41 +302,26 @@
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.
-
-* If we go with this proposal, we will have to decide whether to use
- this feature for existing language-defined packages
- (e.g. Unbounded_Strings), and if so, whether certain existing
- functions should be eliminated from the packages (e.g. overloadings
- of "&" and the comparison operators that have String as one of
- the operand types). At this stage it might be safer to define a
- new package and move the original Unbounded_Strings package to
- Annex J.
-
- Alternatively, we could define some kind of "preference"
- for or against user-defined interpretation of literals, though we
- know that "Beaujolais" effects are lurking around the corner when
- you set up preference rules. We already have some preference rules
- dealing with "root" numeric types, and these could be seen as similar,
- but the root-numeric-type preference avoids Beaujolais effects because
- the preference is for operations that are always visible.
- So barring some clear proof of being Beaujolais-effect-free, we should
- probably steer clear of a preference rule.
+* We have decided not to use this feature for existing language-defined
+ packages (such as Unbounded_Strings). We believe it would be safer to
+ define (in some future standard) a new package and move the original
+ Unbounded_Strings package to Annex J.
!examples
- type Unbounded_String is private
- with String_Literal => To_Unbounded_String;
+ type Varying_String is private
+ with String_Literal => To_Varying_String;
- function To_Unbounded_String (Source : Wide_Wide_String)
- return Unbounded_String;
+ function To_Varying_String (Source : Wide_Wide_String)
+ return Varying_String;
...
- X : constant Unbounded_String := "This is a test";
+ X : constant Varying_String := "This is a test";
-- Equivalent to:
- -- X : constant Unbounded_String :=
- -- To_Unbounded_String
+ -- X : constant Varying_String :=
+ -- To_Varying_String
-- (Wide_Wide_String'("This is a test"));
type Big_Integer is private
@@ -856,7 +867,8 @@
handled by an equivalence rule, then it should be.
T'("abc")
is equivalent to
- T'(T'String_Literal_Function (Wide_String_Param => "abc")) and we don't need to say any more than that about the bounds of the Wide_Wide_String literal.
+ T'(T'String_Literal_Function (Wide_String_Param => "abc")) and we don't
+need to say any more than that about the bounds of the Wide_Wide_String literal.
Note that the parameter subtype of the String_Literal function can be
constrained.
@@ -1316,3 +1328,114 @@
****************************************************************
+From: Randy Brukardt
+Sent: Wednesday, November 28, 2018 1:03 AM
+
+(1) This AI will be split into three AIs as requested. The string and character
+versions will build on the rules given in the base AI for numeric literals.
+
+(2) The summary is "** TBD". That won't get past editorial review (right,
+John??).
+
+I changed it to "A mechanism for user-defined <blah> literals is added."
+(where <blah> is appropriate for the AI).
+
+(3) The first line of my meeting notes says that "We need numeric_literals
+that are non-static, so 4.9(3) needs an update." This wasn't in the AI that
+Tucker sent, so I changed this to:
+
+ * a numeric_literal {of a numeric type};
+
+ AARM Ramification: A numeric_literal {of a numeric type} is always a
+ static expression, even if its expected type is not that of a static
+ subtype. However, if its value is explicitly converted to, or qualified
+ by, a nonstatic subtype, the resulting expression is nonstatic.
+ {Non-numeric types can have numeric literals if aspect Integer_Literal
+ or Real_Literal is used; these are never static.}
+
+I used this wording so as to leave the meaning unchanged in existing cases.
+(Else I would have used "of a static subtype".)
+
+(4) In e-mail, we agreed to limit the Bounded Error to raising exceptions
+only at the location of a literal. That is not reflected in the Bounded
+Error wording in the AI. I've corrected the wording for this:
+
+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.
+
+[We always allow Program_Error to be raised by a Bounded Error.]
+
+(5) I had pointed out the insertion marks in the change for 4.2(9) are screwed
+up; but those were not fixed. I've corrected that paragraph as follows:
+
+Modify paragraph 4.2(9):
+
+ {If its expected type is a numeric type, t}[T]he 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).}
+
+(6) The AI has "Add section 4.2.1 ...". But this is a "subclause", not a
+"section". Fixed accordingly.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, November 28, 2018 1:21 AM
+
+Pushed send too soon.
+
+(7) In e-mail 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.
+
+(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.
+
+(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.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent