CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2000/03/15 18:52:56	1.12
+++ ais/ai-00224.txt	2000/03/16 21:43:10	1.13
@@ -2211,3 +2211,216 @@
 
 *************************************************************
 
+From: Robert Dewar
+Sent: Wednesday, March 15, 2000 2:18 PM
+
+<<That's not helpful. Five years from now, I am not likely to remember that
+I'm not supposed to use Suppress...On for  some obscure reason. And other
+programmers who might work on the source don't know about this discussion in
+the first place.
+>>
+
+I find this argument *very* weak, and would not take it into
+consideration. If you are saying that the standard must enforce
+your particular coding standards that seems unreasonable.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 15, 2000 6:59 PM
+
+> <<That's not helpful. Five years from now, I am not likely to remember that
+> I'm not supposed to use Suppress...On for  some obscure reason. And other
+> programmers who might work on the source don't know about this discussion in
+> the first place.
+> >>
+>
+> I find this argument *very* weak, and would not take it into
+> consideration. If you are saying that the standard must enforce
+> your particular coding standards that seems unreasonable.
+
+I'm pretty tired of this discussion, and we've agreed on all of the other
+points, but I'll make one last try here.
+
+I would agree with your comment on coding standards. The problem is, the only
+reason coding standards are involved at all is that non-specific Unsuppress is
+defined not to affect Suppress...On. If
+
+    pragma Unsuppress (All_Checks);
+
+insisted that all checks are performed (no matter how they were suppressed),
+then the subject of "coding standards" would not come up.
+
+I offered a compromise position of having the language enforce the "coding
+standard" of no Suppress...On pragmas, but people consider that "weak".
+
+Well, fine. I withdraw that compromise.
+
+I have heard no technical argument as to why pragma Unsuppress (without an "On")
+cannot revoke checks suppressed by any kind of Suppress pragma. The arguments
+against Unsuppress...On do not apply here: "Make all checks" is unambiguous and
+certainly not implementation-dependent.
+
+I haven't heard any implementation-related arguments against this, either. I
+suppose there might be some, but I'd like to hear them.
+
+The only arguments I've heard against it are (1) it makes the semantics of
+Unsuppress...On confusing; and (2) GNAT doesn't do it that way.
+
+(1) is a red herring now, as we've decided that the RM will not contain
+Unsuppress...On (other than a permission for GNAT and other compilers to include
+it with implementation-defined semantics). What an implementation-defined pragma
+means to some compiler is entirely up to that implementor. And anyone that wants
+portable code certainly won't use it.
+
+(2) doesn't seem real either. Robert has said that he considers any program that
+depends on a specific check being suppressed is broken. If GNAT was changed to
+"do it this way" (that is, having the RM-defined Unsuppress revoke checks on any
+Suppress with the same check name, including Suppress...On), it certainly could
+not break any existing code. The only harm it could possibly do is cause some
+check to be made that was not made before. And Robert has said that any program
+which failed as a result would be broken. Thus I find the GNAT argument -- in
+this one specific case -- to be "very weak", as Robert put it.
+
+Certainly, this would be a far less disruptive change than forcing GNAT to
+"unimplement" something, or changing the meaning of Unsuppress...On. And it
+makes the meaning of Unsuppress far more intuitive, and makes it useful in the
+*absence* of coding standards. And it has simpler RM wording as well (because we
+don't have discuss Suppress...On separately when defining Unsuppress).
+
+So I await any technical or implementation arguments against this.
+
+			Randy.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 15, 2000 7:13 PM
+
+<<(2) doesn't seem real either. Robert has said that he considers any program
+that depends on a specific check being suppressed is broken. If GNAT was
+changed to "do it this way" (that is, having the RM-defined Unsuppress
+revoke checks on any Suppress with the same check name, including
+Suppress...On), it certainly could not break any existing code. The only
+harm it could possibly do is cause some check to be made that was not made
+before. And Robert has said that any program which failed as a result would
+be broken. Thus I find the GNAT argument -- in this one specific case -- to
+be "very weak", as Robert put it.
+>>
+
+I find that a possibility, and do not strongly object to this idea.
+
+However, in practice I find the only useful use of Unsuppress to be
+to undo a compiler option that suppresses checks.
+
+I find it a big bogus to worry about a program that uses a suppress on
+a specific entity and in a nested range needs to unsuppress it without
+knowing that it is there.
+
+Remember we are only talking static nesting here, i.e. the suppress
+and unsuppress would have to be in the same package for Randy's worry
+to apply.
+
+It seems *awfully* theoretical to me ...
+
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 15, 2000 7:35 PM
+
+> I find it a big bogus to worry about a program that uses a suppress on
+> a specific entity and in a nested range needs to unsuppress it without
+> knowing that it is there.
+
+A Suppress...On can be used in a package specification, and would apply to that
+entity anywhere it is used. (It applies to the entire scope of the entity, which
+essentially is the whole program).
+
+That's the case I'm worried about. I don't find that all that unlikely; it
+certainly doesn't have to be in the same source file.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 15, 2000 8:58 PM
+
+<<A Suppress...On can be used in a package specification, and would apply to
+that entity anywhere it is used. (It applies to the entire scope of the
+entity, which essentially is the whole program).
+
+That's the case I'm worried about. I don't find that all that unlikely; it
+certainly doesn't have to be in the same source file.
+>>
+
+I find this level of worry completely and utterly unconvincing. This is
+simply not what Unsuppress is useful for in practice.
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, March 16, 2000 2:39 AM
+
+I must confess that I'm getting lost in this discussion, but it seems clear
+to me that the difficulty is in the definition of Unsuppress in relation to
+Suppress.
+Why not abandon the idea of "unsuppressing", and rather have a pragma Force,
+with a simpler semantics, something like:
+
+pragma Force (identifier[, [On =>] name]);
+The values of "identifier" are as defined for pragma Suppress. When in the
+scope of a pragma Force, the corresponding checks are always in effect. Any
+inner pragma Suppress will have no effect on entities to which a pragma
+Force applies".
+
+There is no contradiction, since a pragma Suppress can always be ignored.
+There is no incompatibility, since existing implementation can still provide
+pragma Unsuppress if they wish.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, March 16, 2000 11:02 AM
+
+> Why not abandon the idea of "unsuppressing", and rather have
+> a pragma Force,
+> with a simpler semantics, something like:
+>
+> pragma Force (identifier[, [On =>] name]);
+
+This is *exactly* where I started with pragma "Require". With exactly the
+definition that Jean-Pierre recommends.
+
+Of course, I was shouted down on that one. I think it would be pretty crazy to
+revert the entire thing to the original version.
+
+As it stands, I plan to write it up only with non-specific Unsuppress, an
+implementation permission to support Unsuppress...On with implementation-defined
+semantics, and the rule I outlined earlier (because it is easier to describe and
+use). If it turns out that there are substantial implementation concerns, we can
+revisit that detail.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Thursday, March 16, 2000 8:06 AM
+
+> I'm pretty tired of this discussion, and we've agreed on all of the other
+> points, but I'll make one last try here.
+
+As usual, we spend the most energy arguing about the least important
+issues.  ;-)
+
+I can go along with Randy's idea, so long as we agree that it's not
+harder to implement.  I don't have evidence that it *is* harder.
+I just think implementation difficulty should be the overriding concern,
+given that "On=>" is so rarely used, and ill-defined anyway.
+
+We have implemented pragma Unsuppress at AverStar, and I *think* we did
+this "On=>" stuff the same way as GNAT.
+
+So: I could agree to any of (1) the GNAT way, (2) Randy's way, or (3)
+implementation defined.
+
+*************************************************************
+