CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	1999/11/23 04:17:54	1.3
+++ ais/ai-00224.txt	1999/11/23 23:58:34	1.4
@@ -328,3 +328,214 @@
 
 *************************************************************
 
+From: John Barnes
+Sent: Tuesday, November 23, 1999 4:37 AM
+
+I don't  like the word Require either. It's a perfectly good word that
+might be useful elsewhere whereas Unsuppress is a nasty word that is
+most unlikely to be confused with anything else.
+
+I would like to feel that the words have some symmetry.
+
+John
+
+*************************************************************
+
+From: Stephen Michell
+Sent: Tuesday, November 23, 1999 7:19 AM
+
+John Barnes wrote:
+
+> I don't like the word Require either. It's a perfectly good word that
+> might be useful elsewhere whereas Unsuppress is a nasty word that is
+> most unlikely to be confused with anything else.
+>
+
+An excellent point. Then Ada could be the language with the nastiest keywords
+in town. No one would DARE critisize us then (at least - not to our faces).
+
+> I would like to feel that the words have some symmetry.
+>
+
+It does seem clear that "unsuppress" is now in current usage and in the
+lexicon of the community, so that is the way it must remain. It is also clear
+to me that one can never permanently override the effects of the other, once
+it has been selected.
+
+It may be reasonable, however, to create a pragma "require" that is a
+configuration pragma. Such a pragma couldn't override pragma suppress in code,
+it would just fail the compile. That could be a useful way of ensuring that
+there are no checks suppressed in your 5 million line program.
+
+  ...stephen
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 23, 1999 8:28 AM
+
+Obviously the non-nesting semantics would take more work in GNAT, since it
+is already done using stacking semantics. That was what I meant. We
+implemented the stacking semantics because it seems clearly preferable.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 23, 1999 8:27 AM
+
+I find a stacking semantics far more natural here, and in fact the more
+I think about it, the more I think your non-stacking semantics is
+fundamentally flawed.
+
+If I write a little section of code which depends on correctness on the
+fact that checks are suppressed, say for performance reasons in the
+context of a particular compiler, it should not be possible to destroy
+the correctness of this code by nesting it within a construct that contains
+an Unsuppress and knows nothing about the code nested within it.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 23, 1999 8:38 AM
+
+One more point on stacking semantics
+
+It seems clear to me that Suppress and Unsuppress should be symmetrical
+in their semantics. Anything else would be a surprise.
+
+Given that it seems clear that a higher level Suppress cannot mask a lower
+level Unsuppress, indeed in some sense that's the whole point of Unsuppress
+(to undo a higher level Suppress).
+
+So it would indeed seem odd if a Suppress cannot undo the effect of a higher
+level Unsuppress.
+
+I think part of the problem here is that Randy may have been trying to solve
+a problem that Unsuppress is definitely NOT intended to address, and one
+which to me is a non-problem, namely trying to ensure that checks are not
+suppressed anywhere in your program.
+
+Why do I think that is a non-problem? Simply because I have never run into
+a customer requirement or an internal reqiurement for such a feature.
+
+Unsuppress was put there solely for local control in situations which need
+local control. Thus the stacking semantics seems much more natural to me.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 23, 1999 8:18 AM
+
+<<It may be reasonable, however, to create a pragma "require" that is a
+configuration pragma. Such a pragma couldn't override pragma suppress in code,
+it would just fail the compile. That could be a useful way of ensuring that
+there are no checks suppressed in your 5 million line program.
+>>
+
+This seems overkill to me, I am really not aware of any requirements here.
+After all Ada is full of deliberate loopholes to get around "checks",
+most notably unchecked conversion and address clauses, why get all
+upset about some local use of Suppress?
+
+*************************************************************
+
+From: Stephen Michell
+Sent: Tuesday, November 23, 1999 11:33 AM
+
+  Sure, and the first thing that real projects do is write coding standards that
+break peoples' fingers if they dare use one of those. Just ask me - I came back
+Sunday from a week in the UK where those were some of the project's major
+topics, and some people walked away with bandaged fingers :). Incidently, this
+project does extremely heavy numeric calculations, numerical integrations of
+transendental functions, we do not suppress any checks, and performance is not
+an issue.
+
+The point is that Ada's loopholes are a real problem for real projects. We have
+to do a lot of work to make sure that they are not used. Sure one can build
+external tools to check for such things, but then one could code on C and rely
+on external tools - right? Our community believes that the compilation
+environment is the best line of defence for these issue, so let's seriously
+consider ones that provide a real benefit.
+
+A thought - The Annex H "pragma Restrictions" is helpful for many of the
+significant issues, such as No_Allocation, No_Unchecked_Conversion, but
+"no_pragma_suppress" is not one of the restrictions. Maybe that is the solution.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 23, 1999 2:02 PM
+
+> I find a stacking semantics far more natural here, and in fact the
+> more I think about it, the more I think your non-stacking semantics
+> is fundamentally flawed.
+>
+> If I write a little section of code which depends on correctness on
+> the fact that checks are suppressed, say for performance reasons in
+> the context of a particular compiler, it should not be possible to
+> destroy the correctness of this code by nesting it within a construct
+> that contains an Unsuppress and knows nothing about the code nested
+> within it.
+
+I find this a pretty compelling argument in practice (even though a
+"correct" program can't depend on Suppress). I couldn't think of a case
+where it would matter when I wrote the AI.
+
+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.
+
+I'll rewrite the AI and repost it sometime after Thanksgiving.
+
+				Randy.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 23, 1999 2:45 PM
+
+> I think part of the problem here is that Randy may have been trying to solve
+> a problem that Unsuppress is definitely NOT intended to address, and one
+> which to me is a non-problem, namely trying to ensure that checks are not
+> suppressed anywhere in your program.
+
+Well, actually, I was trying to provide a way to insure (typically in a local
+section of code) that checking *is* done. That's because the person who writes
+the code is lot more likely to know the requirements of the code. That has to
+work no matter what configuration pragmas, compiler options, or whatever happen.
+"Unsuppress" seems to be the wrong name for this purpose, because it does not
+necessarily have anything to do with a Suppress. (I can live with it though).
+
+The non-stacking part came from two issues: the difficulty of writing wording to
+explain stacking formally, and to give meaning to the pragma when given as a
+configuration pragma. (Remember that Suppress can be a configuration pragma).
+The GNAT Unsuppress appears to be always ignored when given as a configuration
+pragma. I'm not very excited about requiring compilers to implement a pragma
+that will always be ignored.
+
+An interesting question: if both a Suppress and Unsuppress are given in the same
+scope, what happens? Does the order matter. For instance,
+
+       procedure ...
+           pragma Suppress (All_Checks);
+           pragma Unsuppress (Storage_Check);
+
+Does this Suppress all checks except Storage_Check?
+
+       procedure ...
+           pragma Unsuppress (Storage_Check);
+           pragma Suppress (All_Checks);
+
+Does this Suppress all checks including Storage_Check?
+
+The problem is that configuration pragmas really don't have an order, so we
+can't tell which came first. If the meaning depends in the order that they're
+seen in, then using both Suppress and Unsuppress as configuration pragmas is
+implementation-dependent. Ugh.
+
+			Randy.
+
+*************************************************************
+