CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	1999/11/23 23:58:34	1.4
+++ ais/ai-00224.txt	1999/11/29 21:12:58	1.5
@@ -539,3 +539,184 @@
 
 *************************************************************
 
+From: Jean-Pierre Rosen
+Sent: Wednesday, November 24, 1999 1:44 AM
+
+> I've thought about it some more, and while the "stacking" semantics is easy
+> to describe informally, a formal description seems difficult. I don't think
+> that any of the existing Ada pragmas work this way (can anyone think of a
+> counter-example)? Any suggestions of how to word this? All I can think of is
+> "revoking the permission to suppress checks", but that is a double negative.
+>
+What's the problem ? The pragma applies to the declarative region where it
+appears. In the case of nesting, the innermost wins.
+Just state that you cannot have a suppress and an unsuppress in the same
+declarative region for the same check (on the same object).
+This is the natural Ada semantics.
+
+*************************************************************
+
+From: Robert I. Eachus
+Sent: Friday, November 26, 1999 4:24 PM
+
+I personally would find a non-stacking version of Unsuppress to be a problem,
+even if it is never used in a stacking situation.  This is for code verification
+reasons.  With the GNAT version, you just have to look at the closest nested
+pragma, and if it matters to the logic of the code, the author will located it
+as close as possible to the affected code to make verification easy.
+
+Also, in the case of generics and in-line code, the fact that the code depended
+on exceptions would need to be made visible to the user.
+
+                                        Robert I. Eachus
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 29, 1999 5:09 AM
+
+<<In the case of nesting, the innermost wins.
+Just state that you cannot have a suppress and an unsuppress in the same
+declarative region for the same check (on the same object).
+This is the natural Ada semantics.
+>>
+
+We don't have any such restriction in GNAT, and
+
+a) I see no reason for such a restriction, the semantics is natural, a
+suppress cancels a previous unsuppress and vice versa.
+
+b) This is used in practice sometimes to just unsupress checks for an
+individual statement or suppress them for an individual statement. Yes
+you could declare a block for this, but why require this.
+
+It would require extra mechanism to enforce such a restriction, since
+it would mean that you not only have to have a flag indicating the
+restriction, but also another flag indicating whether it was explicitly
+set in the current scope.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 29, 1999 9:55 AM
+
+>Jean-Pierre says:
+
+> What's the problem ? The pragma applies to the declarative region where it
+> appears.
+
+How do you describe what Unsuppress does??? In this semantics, it doesn't do
+anything by itself. It can only be described in terms of some (outer?) Suppress;
+which leads to the double negative wording.
+
+> In the case of nesting, the innermost wins.
+> Just state that you cannot have a suppress and an unsuppress in the same
+> declarative region for the same check (on the same object).
+
+Given that the language-defined checks include some that overlap (the obvious
+one is All_Checks and everything else), this could be quite difficult to do.
+
+> This is the natural Ada semantics.
+
+Yes, if you make that restriction. But the restriction isn't natural, and it
+isn't easy to describe.
+
+---
+
+>Robert Dewar says:
+
+>We don't have any such restriction in GNAT, and
+
+>a) I see no reason for such a restriction, the semantics is natural, a
+>suppress cancels a previous unsuppress and vice versa.
+
+I agree, except that the "order" of the pragmas is not well-defined when they
+are used as configuration pragmas. We could prevent the use of Unsuppress as a
+configuration pragma, but this seems like an unnatural restriction.
+
+>b) This is used in practice sometimes to just unsupress checks for an
+>individual statement or suppress them for an individual statement. Yes
+>you could declare a block for this, but why require this.
+
+Something is wrong with this. By 11.5(5), Suppress (and presumably Unsuppess) is
+only allowed in a declarative_part, package specification, or as a configuration
+pragma. That makes it impossible to use "around a statement" without an
+enclosing block.
+
+>It would require extra mechanism to enforce such a restriction, since
+>it would mean that you not only have to have a flag indicating the
+>restriction, but also another flag indicating whether it was explicitly
+>set in the current scope.
+
+Right. Plus you would have to deal with overlapping checks like All_Checks.
+
+But without the restriction, it takes a lot more words to describe what happens.
+This appears to be a case of "we know what we want, but we don't know how to
+describe it".
+
+			Randy.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, November 29, 1999 10:48 AM
+
+Randy mentioned some concern about Unsuppress used as a configuration
+pragma, as it seemed useless with the "stacking" interpretation.
+However, if we consider a command-line parameter as the "outermost"
+level, then a library-wide configuration pragma, then a compilation-wide
+configuration pragma, then a scope-specific pragma, it seems like
+configuration pragmas would fit into the "stacking" hierarchy in
+a reasonable way.
+
+For example, if you gave a "suppress-all" on the command line, but
+had an Unsuppress for tag check in a library-wide configuration pragma,
+that would seem meaningful and perhaps useful.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 29, 1999 1:31 PM
+
+Tucker says:
+
+> For example, if you gave a "suppress-all" on the command line, but
+> had an Unsuppress for tag check in a library-wide
+> configuration pragma, that would seem meaningful and perhaps useful.
+
+Yes, but the problem is that it has been suggested that the order that
+Suppress and Unsuppress pragmas is significant. That is,
+
+   pragma Suppress (All_Checks);
+   pragma UnSuppress (Overflow_Check);
+
+(which suppresses all but Overflow_Check) means something different than
+
+   pragma UnSuppress (Overflow_Check);
+   pragma Suppress (All_Checks);
+
+(which suppresses all checks), the UnSuppress being ignored.
+
+The problem is that configuration pragmas are not given in a clearly defined
+order. Since they can be compiled separately, and compilation order is not an
+Ada 95 concept, the pragmas could occur in either order or simultaneously.
+Similarly, we cannot say that compiler options occur before or after "real"
+configuration pragmas. So how do we determine which of these are meant?
+
+This means that the definition of configuration pragmas cannot depend on the
+order of appearance. Yet, I've been told to write wording for UnSuppress which
+*does* depend on the order that the pragmas appear. So, we have a problem.
+
+If we get rid of the significance of the order (at least within a single scope),
+we get rid of the problem, but that the cost of complicating things (and I
+suspect that Robert won't go along with any such semantics). [That is, in a
+scope, UnSuppress has precedence over Suppress.] We could also prevent multiple
+pragmas in the same scope, but that is a problem because of overlapping sets of
+checks. Or we could simply eliminate UnSuppress as a configuration pragma, which
+would prevent the problem from occurring. None of these look like particularly
+good choices.
+
+			Randy.
+
+*************************************************************
+