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

--- ai12s/ai12-0249-1.txt	2019/01/25 23:22:54	1.7
+++ ai12s/ai12-0249-1.txt	2019/02/22 07:10:30	1.8
@@ -1,4 +1,4 @@
-!standard 4.2(9)                                     19-01-25  AI12-0249-1/05
+!standard 4.2(9)                                     19-02-22  AI12-0249-1/06
 !standard 4.2.1(0)
 !standard 4.9(3)
 !class Amendment 18-01-22
@@ -11,7 +11,8 @@
 !subject User-defined numeric literals
 !summary
 
-A mechanism for user-defined numeric literals is added.
+A mechanism for giving a user-defined meaning to numeric literals is added
+to Ada.
 
 !problem
 
@@ -27,7 +28,9 @@
 
 !proposal
 
-Aspects will be defined to allow a type to use numeric literals.
+Aspects will be defined to allow the lexical numeric literals to be defined
+to be used with a (non-numeric) type. The aspect identifies a subprogram to
+be used to interpret the literal as a value of the type.
 
 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 
@@ -102,11 +105,16 @@
 
   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
+For the evaluation of an integer literal with expected type
+having an Integer_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.
+to the textual representation of the integer literal. Similarly,
+the evaluation of a real literal with expected type
+having a 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 or real literal.
 
   Bounded Errors
 
@@ -252,11 +260,16 @@
 
 @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
+For the evaluation of an integer literal with expected type
+having an Integer_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.
+to the textual representation of the integer literal. Similarly,
+the evaluation of a real literal with expected type
+having a 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 or real literal.
 
 @s8<@i<Bounded Errors>>
 
@@ -1525,5 +1538,118 @@
 Sent: Sunday, December 2, 2018  10:59 AM
 
 Works for me!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, February 19, 2019  6:44 PM
+
+Tucker Taft wrote a while back: [Editors Note: The thread this was from is 
+filed in AI12-0208-1.]
+
+...
+> The point of AI-249 is not to support odd-ball syntaxes for literals, 
+> but rather to allow the *existing* syntax for numeric literals to be 
+> used with private types.  If the AI made you think that users were 
+> being given the opportunity to invent some new kind of syntax for 
+> literals, it definitely needs to be clarified.  The first thing to 
+> change is the !subject -- instead of "user-defined numeric literals" 
+> it should be "numeric literals for user-defined types."  And we should 
+> use that terminology throughout, rather than ever saying "user-defined 
+> literals."  We really are not supporting that in this AI.
+
+I strongly disagree with this statement/proposal to change the terminology to 
+"numeric literals for user-defined types". I was planning to ignore it, but 
+since John is insisting on such a change, I need to make my reasons known.
+
+First of all, "user-defined types" is nonsense. It describes pretty much every
+type in an Ada program. And the handful of types it doesn't describe includes 
+the motivating case for the feature -- the language-defined Big_Integer and 
+Big_Real types.
+
+Second of all, the term "user-defined <blah>" has a long history of being used 
+in an Ada context to mean a user-defined meaning for something. It has never 
+meant allowing new lexical or syntactic items, just letting the user ascribe 
+a meaning for existing lexical/syntax items.
+
+In particular, 4.1.6 is titled "User-Defined Indexing". This doesn't mean you 
+get to use square brackets or some emojies to define indexing! It lets you 
+give a user-defined meaning to the existing () notation. (And really, it is 
+barely that.)
+
+4.2.1 is (currently) titled "User-Defined Literals", there is only one 
+subclause separating 4.1.6 and 4.2.1. It would look bizarre to use different 
+terminology in 4.2.1 and in 4.1.6.
+
+Consistency alone would strongly suggest leaving the presentation as it is, as 
+that is how we have presented such features in the past.
+
+---
+
+I don't really understand John's confusion, nor why my 3 different private 
+messages to him on the topic didn't succeed in dispelling that confusion.
+The primary purpose has always been to allow (existing) literals to be used 
+with abstract data types; there didn't seem to be any reason to limit the 
+feature *just* to ADTs (read, private types), since the feature has to make 
+sense for the full type of any private type anyway.
+
+I agree that "user-defined" isn't the best terminology to use (here or 
+anywhere), but I don't think inventing new terminology is necessarily going to
+help, as it would be more confusing to someone reading the future RM to have 
+multiple presentations for what is essentially the same concept.
+
+I could see modifying the !problem and !proposal of the AI to emphasize ADTs 
+and the fact that we are talking about existing lexical literals, but that 
+doesn't require any changes to the !wording nor the !subject (and probably not 
+the !summary, either.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, February 19, 2019  6:58 PM
+
+> Second of all, the term "user-defined <blah>" has a long history of 
+> being used in an Ada context to mean a user-defined meaning for 
+> something. It has never meant allowing new lexical or syntactic items, 
+> just letting the user ascribe a meaning for existing lexical/syntax items.
+> 
+> In particular, 4.1.6 is titled "User-Defined Indexing". This doesn't 
+> mean you get to use square brackets or some emojies to define 
+> indexing! It lets you give a user-defined meaning to the existing () notation.
+
+This argument for calling the section "User-Defined Numeric Literals" 
+makes sense to me.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February 19, 2019  9:41 PM
+
+I agree that for consistency with other similar sections, "User-Defined 
+Numeric Literals" might make sense as a (sub)clause title, but it also seems 
+clear that John, and perhaps others, were confused by the terminology used in
+the AI.  I think in the RM introduction to the section, and in the AI, we can
+emphasize that we are allowing (normal, everyday) numeric literals to be used
+with non-numeric, most likely private, types.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, February 20, 2019  2:40 AM
+
+> ...
+>> The first thing to change is the
+>> !subject -- instead of "user-defined numeric literals" it should be 
+>> "numeric literals for user-defined types."  [...]
+
+> I strongly disagree with this statement/proposal to change the 
+> terminology to "numeric literals for user-defined types".
+Here I agree with both sides: the literals themselves are not "user-defined",
+but talking about "user-defined types" in a language where all types obey the
+same rules makes me uncomfortable.
+
+So I propose "user defined interpretation of numeric literals". It is a bit 
+longer, but it conveys the right idea. Of course, someone may suggest a better 
+word than "interpretation": meaning, transformation, magic...
 
 ****************************************************************