CVS difference for ais/ai-00329.txt
--- ais/ai-00329.txt 2006/01/10 22:17:47 1.9
+++ ais/ai-00329.txt 2006/02/21 04:21:48 1.10
@@ -16,10 +16,7 @@
Pragma No_Return specifies that a procedure never returns "normally" but rather
can return only by propagating an exception.
-Ada.Exceptions.Raise_Exception is changed to always raise an exception,
-and has pragma No_Return apply to it. If Raise_Exception is passed
-Null_Id, it raises Constraint_Error, like several of the other operations
-in Ada.Exceptions.
+Ada.Exceptions.Raise_Exception has pragma No_Return apply to it.
!problem
@@ -49,9 +46,8 @@
if the procedure completes normally by reaching the end
of its body (just as with a function).
-Change the definition of Ada.Exceptions.Raise_Exception
-to raise Constraint_Error if given Null_Id, and mark it
-as a No_Return procedure.
+Mark Ada.Exceptions.Raise_Exception as a No_Return procedure. (This requires
+the change in AI-446 to always raise an exception.)
!wording
@@ -91,11 +87,6 @@
pragma No_Return(Raise_Exception);
-Modify 11.4.1(14) as follows:
-
- [Raise_Exception and] Reraise_Occurrence [have] {has} no effect in the case
- of [Null_Id or] Null_Occurrence. {Raise_Exception,} Exception_Message, ...
-
!example
procedure Fatal_Error(Msg : String);
@@ -193,24 +184,6 @@
presuming GNAT users take warnings seriously. (We guess
they do in that GNAT has a "treat warnings as errors" flag.)
-Raise_Exception
-
-The existing situation where Raise_Exception has no effect when passed Null_Id
-seems to be of little value. Being able to declare Raise_Exception as a
-No_Return procedure would have significant value, since it is essentially
-always used that way. To be consistent with other subprograms in this package,
-it would seem best to raise Constraint_Error when Raise_Exception is given a
-Null_Id (though Program_Error would be another reasonable choice).
-
-We considered having this pragma apply to Ada.Exceptions.Reraise_Occurrence as
-well. It has no effect when Null_Occurrence is passed, and that would need to
-change in order to apply the pragma. However, it is not unusual to pass the
-occurrence of an exception to other code to delay raising it. If there was no
-exception, passing Null_Occurrence for this works fine. Moreover, as there is
-no test for Null_Occurrence in Ada 95, this is the only way to write such code
-without additional flags. Thus, we considered the incompatibility unacceptable
-for Reraise_Occurrence.
-
!corrigendum 6.5.1(1)
@dinsc
@@ -256,17 +229,6 @@
@b<function> Exception_Message(X : Exception_Occurrence) @b<return> String;
@b<procedure> Reraise_Occurrence(X : @b<in> Exception_Occurrence);>
-!corrigendum 11.4.1(14)
-
-@drepl
-Raise_Exception and Reraise_Occurrence have no effect in the case of Null_Id or
-Null_Occurrence. Exception_Message, Exception_Identity, Exception_Name, and
-Exception_Information raise Constraint_Error for a Null_Id or Null_Occurrence.
-@dby
-Reraise_Occurrence has no effect in the case of Null_Occurrence.
-Raise_Exception, Exception_Message, Exception_Identity, Exception_Name, and
-Exception_Information raise Constraint_Error for a Null_Id or Null_Occurrence.
-
!ACATS test
Create an ACATS C-Test to check that a procedure with No_Return raises
@@ -757,556 +719,6 @@
Sent: Monday, March 1, 2004 8:04 PM
No problem, I just posted version /03 that solves this problem.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Thursday, December 8, 2005 11:45 AM
-
-For the record, we already implemented this as
-described, namely maintaining a difference between
-Ada 95 behavior (returns silently) and Ada 2005
-behavior (raises CE) when passed a null Exception_Id,
-but again, I would prefer to see Ada 95 compilers
-be allowed to adopt the Ada 2005 behavior (in the
-same way we allowed Ada 83 compilers to adopt the
-8-bit characters of Ada 95).
-
-Either this is a trivial incompatibility, in which
-case why insist on it, or it is not, in which case
-it is a gratuitous non-upwards compatible change.
-
-It seems to me that insisting on different behavior
-in Ada 95 and Ada 2005 is trying to have it both ways.
-
-P.S. by the way, one of the reasons I think it is very
-important to be able to handle Ada 95 and Ada 2005 with
-a common run time is that for the forseeable future I
-envision mixed applications, with some units compiled
-in Ada 95 mode and some in Ada 2005 mode.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, December 8, 2005 1:51 PM
-
-I guess this is another case where I would stick
-with the "Ada 95 is Ada 95" view, and have some
-kind of configuration pragma to request Ada 2005
-semantics for things like this. If you believe
-mixed systems are likely, then you might want
-to make this the default for your customers,
-but I wouldn't expect other vendors to necessarily
-make the same decision about the "default" mode.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Thursday, December 8, 2005 3:17 PM
-
-Well that is of course what we do, but once again
-if the view is that the semantics in this case are
-significantly different enough to worry about in this
-way, then I think it is totally unjustified to have
-introduced this gratuitous non-upwards compatibility.
-
-The only acceptable argument for a non-upwards
-compatibility is that you convince yourself that
-no Ada 95 program will run into the problem. But
-if that is the case, why worry about how Ada 95
-programs treat the situation.
-
-If you think the Ada 95 decision was a mistake, then
-sure, correct it, but that should be a correction to
-Ada 95 (we have plenty of those :-)
-
-And by the way, this particular case is not hard to
-implement with zero overhead at run time, and a common
-library for the two modes (that's absolutely essential,
-and so far we have not had to compromise that
-requirement, though we have had to do some fiddling,
-as in this case).
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, December 8, 2005 2:25 PM
-
-I disagree with Tucker, for the simple reason that the AI with this change
-(AI-241) is classified as a Binding Interpretation. It is *intended* to
-apply to Ada 95. Indeed, the ACATS tests were changed to not require either
-behavior years ago.
-
-The AI was originally written up as an Amendment, but it was changed to a
-Binding Interpretation at a meeting (November 2000). That implies that we
-considered whether it should apply to Ada 95, and decided it should apply to
-Ada 95. (The minutes unfortunately do not record the discussion that leads
-up to changing the status.) Surely we didn't change the status just to make
-more work for the editor!
-
-Ergo, there is no issue here -- what Robert wants is in fact the correct
-interpretation. (Indeed, when Robert asked the very same question back in
-May, he got the very same answer from me.)
-
-There won't be an ACATS test insisting on the change for Ada 95 (because of
-the WG 9 resolution), but there is no test that requires the old behavior,
-either. (And if any are found, it would be quickly repaired.)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Thursday, December 8, 2005 2:35 PM
-
-Given this (which I suppose I should have known!), I disagree
-with Tucker too! If it is a BI, then it *is* Ada 95.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Thursday, December 8, 2005 3:21 PM
-
-> I disagree with Tucker, for the simple reason that the AI with this change
-> (AI-241) is classified as a Binding Interpretation. It is *intended* to
-> apply to Ada 95. Indeed, the ACATS tests were changed to not require either
-> behavior years ago.
-
-Ah ha! What is confusing here is that this change is also written
-up in AI-329. Probably it does not belong there???
-
-OK, I will remove the "and then Ada_Version >= Ada_2005" from our code :-)
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Thursday, December 8, 2005 3:56 PM
-
-I am confused, AI-241 is about testing for null occurrences, it does not
-change the semantics of Raise_Exception with a null exception_id value
-which is what we are talking about here. Randy???
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, December 8, 2005 4:29 PM
-
-My bad; I read "Raise_Exception" as "Raise_Occurrence". I suppose I should
-have actually read your subject line (it was truncated in my mailer).
-
-Anyway, I agree with you that this is another AI that is misclassified. Or
-more accurately, part of it is misclassified. It's silly that we have made a
-significant, incompatible change in this paragraph that applies to Ada 95,
-and yet another change that is far less likely to be incompatible in
-practice in the same paragraph is not supposed to apply to Ada 95.
-
-I'm reluctantly coming to the conclusion that anything short of a complete
-fork in technology (as we did for Ada 95 from Ada 83) is probably going to
-be impractical. There's just too many tiny differences, and clearly there is
-no will to reconcile them. (Our Ada 95 compiler has an Ada 83 switch, but it
-only provides "easy" compatibility; it doesn't try to undo the complex
-resolution changes, for instance. If you need perfect Ada 83 compatibility,
-we still offer a separate Ada 83 product. I wanted to avoid that this time,
-but it is not looking practical.) And I think that truly mixed programs
-won't really be possible (nor are they that likely to be necessary, as was
-the case with Ada 83).
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Thursday, December 8, 2005 4:32 PM
-
-> Anyway, I agree with you that this is another AI that is misclassified. Or
-> more accurately, part of it is misclassified. It's silly that we have made a
-> significant, incompatible change in this paragraph that applies to Ada 95,
-> and yet another change that is far less likely to be incompatible in
-> practice in the same paragraph is not supposed to apply to Ada 95.
-
-Yes, that's what I think, but no big deal, it was easy enough to accomodate
-without any big palava. What we do is to have the compiler recognize calls
-to this procedure (easy to do in our environment), and append a raise after
-the call if operating in Ada 2005 mode.
-
-> I'm reluctantly coming to the conclusion that anything short of a complete
-> fork in technology (as we did for Ada 95 from Ada 83) is probably going to
-> be impractical. There's just too many tiny differences, and clearly there is
-> no will to reconcile them. (Our Ada 95 compiler has an Ada 83 switch, but it
-> only provides "easy" compatibility; it doesn't try to undo the complex
-> resolution changes, for instance. If you need perfect Ada 83 compatibility,
-> we still offer a separate Ada 83 product. I wanted to avoid that this time,
-> but it is not looking practical.) And I think that truly mixed programs
-> won't really be possible (nor are they that likely to be necessary, as was
-> the case with Ada 83).
-
-Well we have implemented over two thirds of the Ada 2005 AI's, including
-almost all the big hard ones. And we have not come to this conclusion, we
-have managed to keep everything unified.
-
-We do have a few tricks, such as
-
-pragma Preelaborate_05;
-
-allowed only in the library, which says you are preelaborate if the
-program withing the library is in Ada 2005 mode, and otherwise you
-are not preelaborate. A bit of a kludge, but manageable.
-
-Neither of the issues I raised are blocking for us, but I do find it
-irritating to introduce incompatibilities, and take the attitude that
-it is just fine for people who want to move to Ada 2005 to face these
-but not fine for people using Ada 95. As I said a few times before,
-we took EXACTLY the opposite view when we allowed Ada 83 compilers
-to implement 8-bit characters.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Thursday, December 8, 2005 11:57 PM
-
-> Yes, that's what I think, but no big deal, it was easy enough to accomodate
-> without any big palava. What we do is to have the compiler recognize calls
-> to this procedure (easy to do in our environment), and append a raise after
-> the call if operating in Ada 2005 mode.
-
-Humm. That certainly would work, but wouldn't that cause trouble for
-implementing No_Return? The routine would raise Program_Error instead of
-Constraint_Error (a No_Return procedure that returns raises Program_Error).
-(Easily fixed by putting the raise conditionally before the routine, or
-eliminating the check if it is done at the point of the call.)
-
-(In our compiler, this is probably about the same as yours. Ada.Exceptions
-is a built-in package, so the compiler knows about the routine; that means
-no problem with No_Return (we can assume that it is OK and not include the
-check), and it can generate a raise rather than a skip if it is Null_Id.)
-
-> > I'm reluctantly coming to the conclusion that anything short of a complete
-> > fork in technology (as we did for Ada 95 from Ada 83) is probably going to
-> > be impractical. There's just too many tiny differences, and clearly there
-> > is no will to reconcile them. (Our Ada 95 compiler has an Ada 83 switch,
-> > but it only provides "easy" compatibility; it doesn't try to undo the
-> > complex resolution changes, for instance. If you need perfect Ada 83
-> > compatibility, we still offer a separate Ada 83 product. I wanted to
-> > avoid that this time, but it is not looking practical.) And I think
-> > that truly mixed programs won't really be possible (nor are they
-> > that likely to be necessary, as was the case with Ada 83).
->
-> Well we have implemented over two thirds of the Ada 2005 AI's, including
-> almost all the big hard ones. And we have not come to this conclusion, we
-> have managed to keep everything unified.
-
-Well, everybody's compilers are different. There just are so many
-interactions between things that trying to get them all perfect seems
-horrible. Adding a mechanism to make things "disappear" from the symbol
-table, for instance, is a multiday job, especially because a pragma would be
-very hard to make work (it would be too late to find the appropriate item).
-
-I'm sure it is possible to do (because pretty much anything is possible with
-enough work), but I'm wondering if starting with a clean slate would be
-better. I don't want to be spending lots of time inventing compatibility
-features rather than actually implementing useful stuff.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, December 9, 2005 7:02 AM
-
-> Humm. That certainly would work, but wouldn't that cause trouble for
-> implementing No_Return? The routine would raise Program_Error instead of
-> Constraint_Error (a No_Return procedure that returns raises Program_Error).
-> (Easily fixed by putting the raise conditionally before the routine, or
-> eliminating the check if it is done at the point of the call.)
-
-No, we don't mark this routine as No_Return, since it already has to be
-specially handled wrt No_Return in Ada 95 mode, and that same circuitry
-works fine in Ada 2005.
-
-> (In our compiler, this is probably about the same as yours. Ada.Exceptions
-> is a built-in package, so the compiler knows about the routine; that means
-> no problem with No_Return (we can assume that it is OK and not include the
-> check), and it can generate a raise rather than a skip if it is Null_Id.)
-
-Right, similar to what I describe above
-
-> Well, everybody's compilers are different. There just are so many
-> interactions between things that trying to get them all perfect seems
-> horrible. Adding a mechanism to make things "disappear" from the symbol
-> table, for instance, is a multiday job, especially because a pragma would be
-> very hard to make work (it would be too late to find the appropriate item).
->
-> I'm sure it is possible to do (because pretty much anything is possible with
-> enough work), but I'm wondering if starting with a clean slate would be
-> better. I don't want to be spending lots of time inventing compatibility
-> features rather than actually implementing useful stuff.
-
-For us, this has been a minimal issue, the only times that it has seemed
-even a vague annoyance are the ones I brought to the attention of this
-list (by far the worst for us is the Wide_Wide stuff in Ada.Exceptions,
-but the mechanism we are adding for that, pragma Implicit_Child, will
-allow cleanups in the way we handle the implicit children of Text_IO
-in any case). And a fork would be FAR more work to deal with in terms
-of qualifying production compilers for dozens of targets.
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Friday, December 9, 2005 4:12 AM
-
-> I would prefer to see Ada 95 compilers
-> be allowed to adopt the Ada 2005 behavior
-
-As we said at the last ARG meeting, we have to consider these issues on a
-case-by-case basis. In this particular instance I tend to agree with
-Robert. Passing a Null_Id to Raise_Exception is probably a bug anyway (no
-reason why anyone would do that) so raising C_E is actually helpful.
-
-Yes, it is unfortunate that this is entangled with the other AI 329
-changes, but that's life.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, December 9, 2005 7:14 AM
-
-OK, so let's see if we can get a consensus on this, because it would
-be a nice cleanup (even though it would be extra work at this stage,
-since I already implemented the kludge to get different behavior in
-the two cases).
-
-By the way, it is not clear to me if the C_E gets raised with the
-given message, or an implementation dependent message (I have taken
-the latter view so far, which seems reasonable to me!)
-
-> Yes, it is unfortunate that this is entangled with the other AI 329
-> changes, but that's life.
-
-Indeed :-)
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Friday, December 9, 2005 7:54 AM
-
-> As we said at the last ARG meeting, we have to consider these issues on a
-> case-by-case basis. In this particular instance I tend to agree with
-> Robert. Passing a Null_Id to Raise_Exception is probably a bug anyway (no
-> reason why anyone would do that) so raising C_E is actually helpful.
-
-I hate to be a curmudgeon on this, but I can see some cases where
-it would be intentional. For example (and this approximates some
-code we have in our run-time system), you have some cleanup that
-you want to do at the end of a routine under all circumstances,
-and then either return or raise an exception to report status
-to the caller. It seems pretty reasonable to store away an exception
-ID that represents the final status of the routine, then do the
-cleanup, and then pass this ID to Raise_Exception, and then return.
-If the ID is Null_Id, then Raise_Exception does nothing, and so
-you end up just returning. If ID is not Null_Id, then an exception
-is raised, and the return is bypassed.
-
-I can particularly see this when you create an Ada wrapper for a "C"
-routine, where you have some kind of status return from the C routine,
-you use that to decide whether to raise an exception or return
-normally, you save away your decision, you then clean up the various
-data structures you created to call the C routine (e.g. null-terminated
-strings, etc.), and then call Raise_Exception followed by return.
-
-For someone who has decided to start the transition to Ada 2005,
-I would assume that they would do some kind of systematic review
-of these kind of issues as part of that process. For someone who
-is sticking with Ada 95, I have trouble understanding why the
-semantics of this should change.
-
-You could say that if I believe the above, then why change the
-semantics in Ada 2005. But I think the decision process is
-somewhat different. For Ada 2005, we want the resulting language
-to be self-consistent, not look like a language with some new
-features bolted on. We are willing to accept some degree of
-upward incompatibility, if we think there are easy workarounds,
-and the problems will show up at compile-time or with an exception
-at run-time. I don't see why those decisions should affect folks
-who are sticking with Ada 95, or at least not until they choose
-to move up to a compiler that uses Ada 2005 semantics where there
-is a conflict (presumably to get a jump on the ultimate transition).
-
-> Yes, it is unfortunate that this is entangled with the other AI 329
-> changes, but that's life.
-
-This seems like *not* something that could be considered
-a Binding Interpretation, even if it were all by itself as
-a separate AI. The existing semantics are well-defined, and
-even potentially useful under certain circumstances. We
-made the decision for Ada 2005 that the existing semantics
-were error prone, but that is for new code. Presumably for
-existing code, the error-prone-ness has already been dealt with.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, December 9, 2005 12:28 PM
-
-> I hate to be a curmudgeon on this, but I can see some cases where
-> it would be intentional. For example (and this approximates some
-> code we have in our run-time system), you have some cleanup that
-> you want to do at the end of a routine under all circumstances,
-> and then either return or raise an exception to report status
-> to the caller. It seems pretty reasonable to store away an exception
-> ID that represents the final status of the routine, then do the
-> cleanup, and then pass this ID to Raise_Exception, and then return.
-> If the ID is Null_Id, then Raise_Exception does nothing, and so
-> you end up just returning. If ID is not Null_Id, then an exception
-> is raised, and the return is bypassed.
-
-If you believe this then you should NEVER have countenanced
-this gratuitous non-upwards compatibility
-
-> For someone who has decided to start the transition to Ada 2005,
-> I would assume that they would do some kind of systematic review
-> of these kind of issues as part of that process. For someone who
-> is sticking with Ada 95, I have trouble understanding why the
-> semantics of this should change.
-
-You must live in another world, and one which would entirely
-prevent ANY of our serious customers moving to Ada 2005. A
-systematic review of millions of lines of code is simply out
-of the question. If this requirement had been true of Ada 95
-it would have been the case that even fewer users would have
-made the transition to Ada 95 (as you know many still have not
-made this transition).
-
-> You could say that if I believe the above, then why change the
-> semantics in Ada 2005. But I think the decision process is
-> somewhat different. For Ada 2005, we want the resulting language
-> to be self-consistent, not look like a language with some new
-> features bolted on. We are willing to accept some degree of
-> upward incompatibility, if we think there are easy workarounds,
-> and the problems will show up at compile-time or with an exception
-> at run-time. I don't see why those decisions should affect folks
-> who are sticking with Ada 95, or at least not until they choose
-> to move up to a compiler that uses Ada 2005 semantics where there
-> is a conflict (presumably to get a jump on the ultimate transition).
-
-Of course such an argument may be valid in some cases, although the
-burden for me is very very high, and I see nothing in Ada 2005 that
-warrants an exception to the principle of no upwards incompatibility
-(I would have handled NOT NULL differently for instance), but the idea
-that it applies to Raise_Exception seems very dubious to me.
-
-After all, this is not causing any major issues now, Ada 95 users
-and vendors have lived with this for a decade, and it is not even
-on the radar screen as a significant problem
->
->> Yes, it is unfortunate that this is entangled with the other AI 329
->> changes, but that's life.
->
-> This seems like *not* something that could be considered
-> a Binding Interpretation, even if it were all by itself as
-> a separate AI. The existing semantics are well-defined, and
-> even potentially useful under certain circumstances. We
-> made the decision for Ada 2005 that the existing semantics
-> were error prone, but that is for new code. Presumably for
-> existing code, the error-prone-ness has already been dealt with.
-
-I doubt it, are you really saying that you think all big systems
-are error free?
-
-Once again I am not arguing from the point of view of implementation
-simplicity here. Indeed if the ARG were to follow the suggestion of
-allowing back porting, it would be a pain in the neck, since I would
-have to undo what has already been done, test again, refile tests,
-worry about getting rid of the garbage ACATS test etc. However, I
-would do that if I could, just so that the situation with users in
-dealing with incompatibilities were clearer.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Friday, December 9, 2005 1:05 PM
-
-> This seems like *not* something that could be considered
-> a Binding Interpretation, even if it were all by itself as
-> a separate AI. The existing semantics are well-defined, and
-> even potentially useful under certain circumstances. We
-> made the decision for Ada 2005 that the existing semantics
-> were error prone, but that is for new code. Presumably for
-> existing code, the error-prone-ness has already been dealt with.
-
-If that's true, then AI-241 should not have been classified a BI. Because
-the same holds true there. In that case, the semantics aren't particularly
-useful, but we agreed that some programs might depend on those semantics
-simply because that was the only way to make the test. So, if anything, I
-think the AI-241 change is more likely in practice.
-
-My objection here is that we have two changes, similar in degree, in the
-*same* paragraph, and yet one is a BI requiring changes in Ada 95, and the
-other is an Amendment not even allowing the change in Ada 95. Does this
-strike anyone else as inconsistent???
-
-So I say, let's reclassify this one (this part of this one) as a BI.
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Saturday, December 10, 2005 4:50 AM
-
-Yes, it surely is inconsistent.
-
-I am open-minded and could be convinced by Tuck's argument (after all, the
-severity of incompatibilities is a judgment call) but then he should
-surely insist to reclassify AI 241 as an Amendment.
-
-****************************************************************
-
-From: Jean-Pierre Rosen
-Sent: Monday, December 12, 2005 3:02 AM
-
-> I hate to be a curmudgeon on this, but I can see some cases where
-> it would be intentional. For example (and this approximates some
-> code we have in our run-time system), you have some cleanup that
-> you want to do at the end of a routine under all circumstances,
-> and then either return or raise an exception to report status
-> to the caller. It seems pretty reasonable to store away an exception
-> ID that represents the final status of the routine, then do the
-> cleanup, and then pass this ID to Raise_Exception, and then return.
-> If the ID is Null_Id, then Raise_Exception does nothing, and so
-> you end up just returning. If ID is not Null_Id, then an exception
-> is raised, and the return is bypassed.
-
-I think this issue was discussed, and the feeling was that if you do
-this, you are much better off saving the *occurrence* and reraising the
-occurrence. And reraising Null_Occurrence still does nothing.
-
-But reraising through the Exception_ID seemed very unlikely.
-
-****************************************************************
-
-From: John Barnes
-Sent: Monday, December 12, 2005 2:08 AM
-
-I thought 241 was reclassified as an amendment. I discuss it in the
-rationale as if it were an amendment.
-
-Maybe we agreed to reclassify it but didn't actually do it.
-
-If so just reclassify it if that solves the problem.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Monday, December 12, 2005 12:57 PM
-
-> I thought 241 was reclassified as an amendment. I discuss it in the
-> rationale as if it were an amendment.
-
-That's backwards. It originally was an Amendment, and we decided to
-reclassify it as a Binding Interpretation. You probably never noticed that
-and failed to make that change in the Rationale.
-
-> Maybe we agreed to reclassify it but didn't actually do it.
->
-> If so just reclassify it if that solves the problem.
-
-Well, reversing a carefully considered decision (either of them) requires
-more careful consideration. I'd be in favor of reclassifying the portion of
-AI-329 relating to Raise_Exception as a Binding Interpretation. As
-Jean-Pierre points out, we carefully considered compatibility and decided it
-wasn't a real issue.
****************************************************************
Questions? Ask the ACAA Technical Agent