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

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

--- ai12s/ai12-0054-1.txt	2013/05/09 01:31:52	1.5
+++ ai12s/ai12-0054-1.txt	2013/06/11 00:30:15	1.6
@@ -628,3 +628,166 @@
 concerned so I didn't push to inject that.)
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, February  3, 2013  10:17 AM
+
+Here is a possible update to the wording proposed for AI12-0054.  It puts the
+rules for raise_expressions in a separate paragraph.  It includes updates to the
+wording of 11.4.1 as well.  It attempts to clarify that the string_expression is
+evaluated before creating the new exception occurrence.
+
+-----------------------
+
+Modify 11.3(4/2) as follows:
+
+   To raise an exception is to raise a new occurrence of that
+   exception@Redundant[, as explained in 11.4]. For the execution of a
+   raise_statement with an exception_name, {the string_expression, if any, is
+   evaluated, and then} the named exception is raised. @Redundant[If a
+   string_expression is present, [the expression is evaluated and] its value is
+   associated with the exception occurrence.] For the execution of a re-raise
+   statement, the exception occurrence that caused transfer of control to the
+   innermost enclosing handler is raised @Redundant[again].
+
+Add the following after 11.3(4/2):
+
+   For a raise_expression, if it occurs @Redundant[statically] within the
+   predicate for a subtype (after expanding any default_expressions used for
+   calls occurring within the predicate), and the subtype is named in a
+   membership_choice, evaluating the raise_expression causes the associated
+   individual membership test to evaluate immediately to True. In other contexts,
+   evaluating a raise_expression begins with the evaluation of the
+   string_expression, if any, and then the named exception is raised, as for a
+   raise_statement.
+
+Modify 11.4.1(10.1/3) as follows:
+
+   Exception_Message returns the message associated with the given
+   Exception_Occurrence. For an occurrence raised by a call to Raise_Exception,
+   the message is the Message parameter passed to Raise_Exception. For the
+   occurrence raised by a raise_statement {or raise_expression} with an
+   exception_name and a string_expression, the message is the {value of the}
+   string_expression. For the occurrence raised by a raise_statement {or
+   raise_expression} with an exception_name but without a string_expression, the
+   message is a string giving implementation-defined information about the
+   exception occurrence. For an occurrence originally raised in some other manner
+   (including by the failure of a language-defined check), the message is an
+   unspecified string. In all cases, Exception_Message returns a string with
+   lower bound 1.
+
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, February  3, 2013  11:42 AM
+
+> Here is a possible update to the wording proposed for AI12-0054.
+
+I don't really think this is an improvement.  Your wording for 11.3(4/2) puts an
+obscure exceptional case first, which is confusing.  My wording puts the
+exceptional case later, where (IMHO) it should be.
+
+Also, you're changing and adding a lot more verbiage, which doesn't seem like a
+good idea.  Some of the wording changes look gratuitous to me (i.e. not fixing
+any real bugs).
+
+>...It puts the
+> rules for raise_expressions in a separate paragraph.  It includes
+>updates to the  wording of 11.4.1 as well.  It attempts to clarify that
+>the string_expression is  evaluated before creating the new exception
+<occurrence.
+
+Well, I claim that that doesn't need clarification.
+
+I also think this discussion is a waste of time.  I'd rather accept your wording
+than continue to argue about it for another week. If everybody but me agrees
+with Tuck, then I'll happily give in.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, February  3, 2013  7:20 PM
+
+> I also think this discussion is a waste of time.  I'd rather accept
+> your wording than continue to argue about it for another week.
+> If everybody but me agrees with Tuck, then I'll happily give in.
+
+I prefer Bob's wording, but really don't care it is amazingly unimportant. I
+also agree with all the points Bob made.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  4, 2013  2:16 PM
+
+> > Here is a possible update to the wording proposed for AI12-0054.
+>
+> I don't really think this is an improvement.  Your wording for
+> 11.3(4/2) puts an obscure exceptional case first, which is confusing.
+> My wording puts the exceptional case later, where (IMHO) it should be.
+
+This I agree with. Steve's suggestion (adding "except as indicated below" or
+something like that to the normal case) is better than Tucker's version.
+
+> Also, you're changing and adding a lot more verbiage, which doesn't
+> seem like a good idea.  Some of the wording changes look gratuitous to
+> me (i.e. not fixing any real bugs).
+
+I'm not as convinced about that.
+
+> >...It puts the
+> > rules for raise_expressions in a separate paragraph.  It includes
+> >updates to the  wording of 11.4.1 as well.  It attempts to
+> clarify that
+> >the string_expression is  evaluated before creating the new
+> exception occurrence.
+>
+> Well, I claim that that doesn't need clarification.
+
+This I agree with as well. We wrote this as a Ramification AI specifically
+because the language is clear enough for everyone other than language lawyers.
+
+> I also think this discussion is a waste of time.  I'd rather accept
+> your wording than continue to argue about it for another week.
+> If everybody but me agrees with Tuck, then I'll happily give in.
+
+Well, I don't like either version; I prefer Steve's enhancement, plus removing
+the redundant marks around the existing text about evaluation of the string
+expression. Something like (here, changes are marked from the AI12-0022-1
+version):
+
+To raise an exception is to raise a new occurrence of that exception Redundant[,
+as explained in 11.4]. For the execution of a raise_statement with an
+exception_name, the named exception is raised. Similarly, {except as noted
+below,} for the evaluation of a raise_expression, the named exception is raised.
+In both of these cases, if a string_expression is present, the expression is
+evaluated and its value is associated with the exception occurrence. For the
+execution of a re-raise statement, the exception occurrence that caused transfer
+of control to the innermost enclosing handler is raised Redundant[again].
+
+This eliminates the only problem with the existing wording vis-a-vis the
+evaluation order (that it is marked as redundant, but there is no other text
+that talks about evaluation of the string_expressions), and eliminates Steve's
+concern that the special case isn't mentioned in the original wording.
+
+I could see adding "value of the" to 11.4.1(10.1/3) [because it's the evaluated
+value, not the expression itself that's associated with the exception
+occurrence], but it's hardly critical (especially if the existing text is not
+thought of as redundant).
+
+Removing the "pun" from the new paragraph would nice, but hardly worth a bunch
+of discussion.
+
+****************************************************************
+
+Editor's note: (February 25, 2013)
+
+This AI failed its letter ballot 10-2-2 (Dewar and Rosen opposing,
+Barnes and Burns abstaining, Baird, Bosch, Brukardt, Cousins,
+Dismukes, Duff, Moore, Ploedereder, Schonberg, Taft in favor). Our rules
+require no opposing votes to for e-mail ballots to pass (rules are looser
+at meetings). Subsequent e-mail discussion led to creating an alternative,
+AI12-0054-2; the e-mail is filed in that AI.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent