CVS difference for ais/ai-00224.txt

Differences between 1.17 and version 1.18
Log of other versions for file ais/ai-00224.txt

--- ais/ai-00224.txt	2000/03/28 01:25:56	1.17
+++ ais/ai-00224.txt	2000/04/11 19:36:33	1.18
@@ -3743,3 +3743,109 @@
 
 *************************************************************
 
+From: Dan Eilers
+Sent: Monday, March 27, 2000 6:42 PM
+
+> Well I trust you implement it to the point of recognizing it and ignoring
+> it (otherwise you could not sign the declaration of conformance). But
+> ignoring it is certainly quite acceptable.
+
+Yes, we recognize it and ignore it, which is what we would continue to
+do if the feature was declared obsolescent.
+
+> Well there is no point in removing this, since that just causes unnecessary
+> incompatibilities, and implementing it is zero effort for compilers.
+
+There's benefit to us in removing the feature from the language.
+It's much easier to explain to people why we ignore an obsolescent
+language feature than it is to explain that the language designers
+mistakenly included this feature.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 27, 2000 7:23 PM
+
+Well perhaps one could argue for moving it to the equivalent of
+annex J, but removing it is undesirable, since this means that
+compilers could fail to recognize it. Look at the problems we
+had with Ada 95 compilers that, despite the intention to the
+contrary, failed to recognize Ada 83 attributes.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Monday, March 27, 2000 5:54 PM
+
+> Is this because you think the feature should not be in the language?
+
+Partly.  My reasoning is:
+
+1. When writing that part of the Ada 95 RM, I realized that the Ada 83
+wording was completely bogus, so I tried hard to come up with some
+wording that nailed it down.  I couldn't, so I conclude that it's hard
+(or maybe I'm just stupid).
+
+2. The feature is rarely used, so the fact that it's not well-defined
+(and that its ill-definedness is hidden) is not such a big deal.
+
+> From my perspective, as long as it is in the language, we ought to
+> at least attempt to have some common approach to supporting it,
+> or at least enumerate the possibilities for the poor user, so they
+> can conclude using Suppress...On is very implementation dependent.
+
+Well, I would not object to a ruling that states in plain English that,
+"Suppress...On is very implementation dependent".  I just think it's a
+useless (and difficult) exercise to try to nail down the semantics.
+
+> The current implication in the RM that Suppress...On is well-defined
+> is quite misleading.
+
+Yes.  I copied that wording from Ada 83, knowing full well that it was
+bogus nonsense.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 28, 2000 5:42 AM
+
+note that we don't need a sweeping statement that Suppress On=> is completely
+implementation dependent (it is NOT allowed to be erroneous of itself, or
+delete your hard disk etc). The only thing about it that is implementation
+dependent is exactly what (sub)set of entities are tested to suppress
+a given check.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, March 28, 2000 1:45 AM
+
+Nailing down the semantics of Suppress...On may be aesthetically pleasing, but
+as others have pointed out, it's hard, and I can't see what benefits it would
+bring to the user community.
+
+You have to be pragmatic here.  Compilers have been supporting Suppress...On for
+more than 15 years.  Because the definition of this pragma is so vague, compiler
+writers have implemented (1) what was reasonably easy to implement and/or (2)
+what the users where interested in.
+
+Any change to Suppress...On would cause the worst case of incompatibility:
+subtle performance changes in existing programs, and programs starting to fail
+because exceptions would be raised (or not raised) in different circumstances.
+
+Speaking for Rational, we would probably not change our implementation of
+Suppress...On even if the ARG came up with a precise definition.  Our users have
+tuned their usage of pragma Suppress...On over time based on what we implement.
+There is no reason to force them to revisit their code just because the ARG
+thought that uniformity in this area was important.  The whole area of checks
+suppression and optimization is vastly implementation-dependent.  We might as
+well acknowledge this fact .
+
+> The current implication in the RM that Suppress...On is well-defined
+> is quite misleading.
+
+I'd be happy with a clear and honest statement saying that Suppress...On is
+unspecified.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent