CVS difference for ais/ai-00361.txt

Differences between 1.7 and version 1.8
Log of other versions for file ais/ai-00361.txt

--- ais/ai-00361.txt	2005/08/05 04:35:44	1.7
+++ ais/ai-00361.txt	2006/02/21 04:21:51	1.8
@@ -1,4 +1,4 @@
-!standard  11.3(2)                                     05-07-20  AI95-00361/05
+!standard  11.3(2)                                     06-02-08  AI95-00361/06
 !standard  11.3(3)
 !standard  11.3(4)
 !standard  11.4.1(10)
@@ -44,8 +44,8 @@
 Replace the second sentence of 11.3(4) by:
 
 For the execution of a raise_statement with an exception_name, the named
-exception is raised. If a string_expression is present, the value of the
-expression is associated with the exception occurrence.
+exception is raised. If a string_expression is present, the expression is
+evaluated and its value is associated with the exception occurrence.
 
 Replace 11.4.1(10) by:
 
@@ -107,10 +107,10 @@
 To @i<raise an exception> is to raise a new occurrence of that exception, as
 explained in 11.4. For the execution of a @fa<raise_statement> with an
 @i<exception_>@fa<name>, the named exception is raised. If a
-@i<string_>@fa<expression> is present, the value of the @fa<expression> 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 again.
+@i<string_>@fa<expression> is present, the @fa<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 again.
 
 !corrigendum 11.4.1(10)
 
@@ -142,5 +142,202 @@
 constructed to test this feature.
 
 !appendix
+
+From: Tucker Taft
+Sent: Wednesday, February  8, 2006  4:43 PM
+
+The Dynamic Semantics for "raise with string_expression"
+never mentions evaluating the expression.  It talks
+about associating the value with the exception occurrence,
+but doesn't explicitly say when it is evaluated:
+
+11.3(4/2)
+
+   ... If a string_expression is present, the value of the
+   expression is associated with the exception occurrence...
+
+In almost all other circumstances of which I am aware,
+we explicitly say "the expression is evaluated" or
+equivalent as part of the dynamic semantics.
+
+Worth fixing?  Easiest fix is probably:
+
+    ... If a string_expression is present, {the expression
+    is evaluated and its value} [the value of the expression]
+    is associated with the exception occurrence...
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, February  8, 2006  7:29 PM
+
+...
+> Worth fixing?  Easiest fix is probably:
+
+Yes, I'd say it's worth fixing.
+
+>     ... If a string_expression is present, {the expression
+>     is evaluated and its value} [the value of the expression]
+>     is associated with the exception occurrence...
+
+Sounds good.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February  8, 2006  8:54 PM
+
+This looks like an editorial change to me, and that can be done pretty much
+at any time. (And I haven't finished the Amendment anyway, I have to wait
+for the resolution of the various discussions.) So I'll make this change.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, February  9, 2006  7:46 AM
+
+> The Dynamic Semantics for "raise with string_expression"
+> never mentions evaluating the expression.
+
+> Worth fixing?
+
+We could fiddle with the document forever.
+At some point we have to declare it done,
+despite the fact that we know it contains bugs.
+
+This particular bug is of little consequence.
+It will not cause compilers to do the wrong thing.
+It will not cause Ada programmers to be confused.
+
+There's always Ada 201X...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February  9, 2006  12:09 PM
+
+> We could fiddle with the document forever.
+> At some point we have to declare it done,
+> despite the fact that we know it contains bugs.
+
+According to Jim Moore, editorial fixes (those that don't change the
+meaning) can be done to these documents at any time, up to ISO publication.
+So we have a long time to be able to fix this sort of stuff.
+
+This one is somewhat marginal to classify as editorial (in that I can't
+imagine any other meaning, but maybe someone else case), so I wouldn't be
+comfortable making this change after submission: but submission hasn't
+happened yet, so we can (and should) still fix this sort of bug.
+
+I don't think we should accept any additional major fixes at this point, no
+matter what. (Currently open issues excepted, of course). So if that leaves
+bugs, so be it. But there is no reason to not fix the missing package error,
+to not fix the syntax of the example in D.5.2, nor to add the missing word
+"evaluate", etc.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February  9, 2006  8:59 PM
+
+>>Worth fixing?
+
+I would just leave this, and if someone thinks it worth
+the effort, fix it with a BI later. I would not make any
+non-substantive changes to the document at this stage.
+As Bob Duff says, "fixing" this "problem" will have
+precisely zero impact.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February  9, 2006  9:01 PM
+
+> This one is somewhat marginal to classify as editorial (in that I can't
+> imagine any other meaning, but maybe someone else case), so I wouldn't be
+> comfortable making this change after submission: but submission hasn't
+> happened yet, so we can (and should) still fix this sort of bug.
+
+I think we should either make another version because there is
+an important reason to do so (e.g. accepting a substantive change
+like the Canadian accept null proposal), or we should leave the
+document completely untouched.
+
+Having multiple versions that differ only in miscellaneous editorial
+points that have no significant at all is not helpful.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February  9, 2006  9:55 PM
+
+This seems essentially editorial, so it seems it is up
+to the editor.  I believe Randy is in the process of
+doing final editorial changes; there is no "final version" yet,
+as far as I know.  Substantive changes are what we
+are very much trying to avoid.  Making editorial
+changes seems to be at the discretion of the editor
+until there is a "final final" version, and Randy implies
+that even after that, obvious typos can be fixed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February  9, 2006  11:06 PM
+
+> I think we should either make another version because there is
+> an important reason to do so (e.g. accepting a substantive change
+> like the Canadian accept null proposal), or we should leave the
+> document completely untouched.
+>
+> Having multiple versions that differ only in miscellaneous editorial
+> points that have no significant at all is not helpful.
+
+I have no idea of what you are talking about at this time. The submission
+draft (Draft 16) hasn't been finalized yet. Because of comments from the
+various National Bodies, including various substantive ones, there is
+roughly 4 pages of changes (which I've been carefully recording) from the
+previous version. This is the version that is getting this change that
+Tucker identified, and that certainly is going to be plenty different than
+the previous draft 15.
+
+Once the submission to WG 9 has been made, you'd have more of a point. But
+I'll still be required by my Ada Europe contract to make carefully formatted
+versions for them to publish. The PDF versions are sure to be updated at
+that time; no one will want the version with the bad page breaks. And to the
+extent that that work uncovers differences between the Amendment and the
+AARM, the other formats of the AARM may be corrected.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, February 10, 2006  8:19 AM
+
+Seems OK to me, but let's avoid a proliferation of different
+versions of the RM that differ insubstantially.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, February 13, 2006  11:32 AM
+
+Let's avoid distributing anything that resembles an RM prematurely.
+
+The Springer version will be the frozen version after JTC1 approval.
+Publish earlier, any you do so at your own risk.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 14, 2006  5:28 AM
+
+We already have!
+
+I absolotely think we must have a preliminary RM, people are
+using Ada 2005 today, and we want to encourage that. We do not
+want people to lose interest while ISO fiddles around.
+
+We just want to make sure we don't have too many different
+versions that differ insubstantially.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent