CVS difference for ais/ai-00224.txt

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

--- ais/ai-00224.txt	2000/03/16 21:43:10	1.13
+++ ais/ai-00224.txt	2000/03/23 01:37:41	1.14
@@ -2424,3 +2424,729 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Thursday, March 16, 2000 11:08 PM
+
+Randy Brukardt wrote:
+>
+> 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.
+
+Does Unsuppress override Suppress...On, even if the Suppress...On is in
+an inner scope?  If not, implementation gets more difficult.  If we can
+assume that Unsuppress overrides Suppress, no matter which came first,
+then that is fairly straightforward -- we first check whether any
+Unsuppress's apply.  If so, we definitely do the check.  If not, we do
+what we currently do to decide whether any Suppress's apply.
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, March 17, 2000 2:41 AM
+
+This is basically what I suggested. And since an Unsuppress would not be
+illegal if there is no corresponding Suppress, I suggested a more
+appropriate name like "Force" or "Require" (Randy's first suggestion). Does
+anyone remember why this initial suggestion was rejected ?
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Thursday, March 16, 2000 11:56 PM
+
+<<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.
+>>
+
+It definitely *is* harder to implement, in fact it is not easily within
+range at all without a lot of fiddling for GNAT. Why? Because now it is
+not good enough to hjust have one status bit for each check, we need 2,
+since suppress/unsuppress is no longer equivalent to just turning the
+suppress flag on and then turning it off.
+
+I don't find Randy's suggestion unreasonable, but I don't think GNAT
+would follow this implementation path.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 17, 2000 12:13 AM
+
+<<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.
+>>
+
+If I understand the rule that Randy refers to is a fule that an Unsuppress
+overrides any inner Suppress, or am I confused.
+
+Anyway, one thing to be clear on here is that GNAT is NOT about to make
+any incompatible changes to Unsuppress. This is a pragma we implemented
+years ago, and we are not about to cause incompatibilities of this kind.
+
+My feeling is that if the result of this discussion on Unsuppress is
+inconmaptible with GNAT, then the pragma should have some other name
+
+It makes no sense to copy an existing feature from one compiler in a form
+different from what is implemented. This leads to more *divergence* when
+the object of the excercise is *convergence*.
+
+I am not being stubborn here, just pragmatic, we cannot cause our customers
+problems due to non-upwards compatible changes.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 17, 2000 7:57 AM
+
+<<This is basically what I suggested. And since an Unsuppress would not be
+illegal if there is no corresponding Suppress, I suggested a more
+appropriate name like "Force" or "Require" (Randy's first suggestion). Does
+anyone remember why this initial suggestion was rejected ? >>
+
+Well for one thing, it does not address the requirement that Unsuppress was
+intended to address (and for which it has been succesfully used for years
+in the GNAT technology!)
+
+Since the entire discussion had a genesis of looking at the Unsuppress
+feature in GNAT to wonder whether it was worth semi-standardizing, this
+is a bit peculiar!
+
+There are two issues here
+
+  1. Worrying about the seldom used "On" forms of Suppress and Unsuppress.
+     It is fine to make sure we don't overspecify or cause implementation
+     burdens here, but worrying about the utility is a complete waste of
+     time in my opinion.
+
+  2. The idea that an unsuppress is illegal if there is no corresponding
+     suppress completely misses the primary and very useful function of
+     Unsuppress, and makes Force/Require completely useless for this
+     purpose.
+
+Perhaps it would be a good idea to restate why Unsuppress is useful in the
+GNAT technology, and why it has been extensively used for years there.
+
+  If you are writing a library (the issue first arose in the GNAT runtime
+  library), then run-time checks in the library have two functions. One to
+  catch bugs in the library itself, and two to report errros that must be
+  reported back to the user (e.g. a Constraint_Error in Calendar, converted
+  back to Time_Error).
+
+  It is useful to be able to write libraries so that they can be compiled
+  with or without checks, with the understanding being that compiling
+  without checks will remove debugging checks. But you can't remove
+  critical checks of the second kind.
+
+  If we did not have Unsuppress, then we would have to have a complex
+  set of rules in the make files about units that must always be
+  compiled with checks on.
+
+The idea above for Force/Require
+
+  a) has nothing to do with the pragma Unsuppress in GNAT
+
+  b) is as far as I am concerned completely useless
+
+  c) raises significant implementation issues
+
+  d) has not been suggested by any actual user
+
+There ... is that a good enough reason for the ARG not rushing around and
+standardizing a new feature out of the blue for which there is zero demand? :-)
+
+Seriously, I can't imagine GNAT implementing the Force/Require in the above
+form, and if the ARG gets into the business of modfiying the language for no
+good reason and causing implementation effort for no gain, it will undermine
+itself if you ask me.
+
+P.S. I think the exactly right thing here is to document ONLY the effect
+of Suppress and Unsuppress as they interact with one another for the
+normal (no ON) case
+
+In the write up you say
+
+a) implementations can provide the ON form of Unsuppress, but are not
+required. For my taste I would require that the implementation of On
+for Unsuppress, implemented be the existing GNAT interpretation, since
+I see no point in allowing or encouraging diversity in a non-required
+non-critical feature. Once again, the GNAT interpretation is that the
+only effect of On in Unsuppress is to cancel the effect (whatever that
+might be) of a previous On in a Suppress for the same entity.
+
+But I don't really care much on this incrdibly unimportant issue, the only
+important thing is to avoid over specification and implementation
+difficulties (it obviously does not make it hard to implement to
+say "do X, but if you don't want to, don't do it" :-)
+
+b) The effect of a general Unsuppress is implementation defined with regard
+to whether it affects specific Suppress with On clauses. Since the effect
+of such suppresses is implementation defined in the first place, this seems
+quite fine.
+
+Actually I think the definition of Suppress (On =>...) is not even
+impleenmtation defined, but implementation dependent ...
+
+Again b) is worrying about an issue that is incredibly unimportant.
+
+
+My point in raising this whole issue (if people can still remember it
+was me who sounded the warning here) was that we need to be careful
+not to overspecify in this very unimportamt and non-critical aspect
+of Unsuppress.
+
+The one thing that should work, and is really useful is for a general
+(non-On) Unsuppress to locally cancel the effects of a more global
+Suppress.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Friday, March 17, 2000 9:38 AM
+
+Robert says:
+
+> I am not being stubborn here, just pragmatic, we cannot cause our customers
+> problems due to non-upwards compatible changes.
+
+I can't get *too* excited if the incompatibility has to do with "On=>",
+but I basically agree -- it doesn't make sense for GNAT to make
+gratuitous changes like this.
+
+I do not like the idea of inventing a different-named pragma (Require,
+Force, whatever).  We have a perfectly good design for Unsuppress,
+except for some obscure oddities related to "On=>" -- those oddities do
+not warrant new pragmas.  And there's probably a fair amount of existing
+code that already uses Unsuppress quite happily.
+
+> Actually I think the definition of Suppress (On =>...) is not even
+> impleenmtation defined, but implementation dependent ...
+
+Actually, the RM *pretends* to define it quite precisely -- RM-11.5(8) says:
+
+    If the pragma includes a name, the permission applies only to checks
+    performed on the named entity, or, for a subtype, on objects and
+    values of its type.
+
+No mention of impl-def or impl-dep.  It's only if you think about that
+carefully that you realize nobody has any idea what it means for a check
+to be performed "on" an entity.  I don't like that sort of wording; it
+seems misleading.
+
+*************************************************************
+
+From: David Emery
+Sent: Friday, March 17, 2000 9:42 AM
+
+Robert says:
+
+>  I am not being stubborn here, just pragmatic, we cannot cause our customers
+>  problems due to non-upwards compatible changes.
+
+Gee, sounds like Bevin Brett :-)  :-)
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 17, 2000 10:07 AM
+
+Right, it defintiely pretends that it is well defined, but since it isn't
+as we know (recent thread having revealed this dirty little secret to those
+not previously familiar -- I have been aware of this for a while :-), the
+result is that it is not implemnetation defined, but implementation
+dependent, i.e. need nto be documented.
+
+We recently had a bug report from someone who did
+
+ A := B;
+
+and suppressed tag checks on A, and was surprised to still get an
+exception :-)
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Friday, March 17, 2000 10:22 AM
+
+Did you fix the bug?  Or declare it to be a feature?  ;-)
+
+Just curious.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 17, 2000 10:26 AM
+
+we declared it to be the way things were, explaining that the RM did
+not require this to work (actually I really think here that the RM
+if it says anything says that the test is NOT "on" A).
+
+*************************************************************
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 17, 2000 3:53 PM
+
+> If I understand the rule that Randy refers to is a rule that an Unsuppress
+> overrides any inner Suppress, or am I confused.
+
+You are confused. We were over all of that the first time with "Require".
+
+An Unsuppress overrides any outer or preceding Suppress only, including
+Suppress...On. An inner Suppress still can suppress checks, even if there is an
+outer Suppress.
+
+> Anyway, one thing to be clear on here is that GNAT is NOT about to make
+> any incompatible changes to Unsuppress. This is a pragma we implemented
+> years ago, and we are not about to cause incompatibilities of
+> this kind.
+
+As I've said many times, this ought not be incompatible except to programs that
+assumed that Unsuppress did not override Suppress...On *and* depend on checks
+being suppressed to function properly.
+
+> I am not being stubborn here, just pragmatic, we cannot cause our customers
+> problems due to non-upwards compatible changes.
+
+The difference between "stubborn" and "pragmatic" is nearly indetectable here.
+In any case, our primary goal is the same (I don't know if others in this
+discussion have the same goal), and thus I'd expect to come up with virtually
+the same solution. I just don't understand making the solution work right 98% of
+the time, when it can work 100% of the time.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 17, 2000 4:52 PM
+
+I find this entire discussion *extremely* frustrating. People are attributing
+long rejected ideas to me, and then setting them up so Robert can use them as an
+excuse to force us to adopt a very dubious (but easy to implement) definition of
+this pragma.
+
+I am here is large part because I'd rather bag groceries than program in C. If
+we can't even agree on something as obvious as this, then bagging groceries is
+starting to look attractive. We have to start responding to each other's
+proposals, and not to ones that were rejected soundly months ago.
+
+----
+
+From a user perspective, and from a definitional perspective, it is clear that
+an inner Unsuppress needs to revoke the permissions on outer Suppresses. But
+people said that last time that it was important to allow "resuppressing"
+checks, and I rewrote the AI that way. I certainly have no intention of
+reverting to my original proposal, and I can see no valid reason to do so.
+
+It is likely that there would be a small implementation cost in supporting that.
+I doubt that there would be any effect on compilation times (since Suppress...On
+is used so rarely), but there would be a bit of effort.
+
+My implementation model for Suppress...On is that there is a list or lists of
+all Suppress...Ons that are active. This is needed so they can be canceled when
+they go out of scope. (Normally, this list would be empty, as Suppress...On is
+rare). Thus, implementing Unsuppress to cancel these means walking this list to
+find ones that need changing, and adding/stacking appropriate information. This
+does not seem difficult or expensive. Certainly, I would not expect that you
+would have to walk the entire symboltable to find such things.
+
+----
+
+As far as Unsuppress...On goes, I think it would be folly to try to define it at
+all. There are so many questions about what entities and checks are involved
+that I don't think we want to get into answering. For instance, two subtypes of
+the same type are different entities, but they clearly control the same check
+(11.5.(8)). What happens when one is Suppressed, and the other Unsuppressed?
+
+Certainly, the easiest thing is to leave it implementation-defined if there is
+such a pragma, and what it means if there is. I can sympathize with Robert's
+concern about incompatible implementations, but this capability is simply
+unimportant -- it isn't useful for bullet-proofing code (the primary concern
+that both Robert and I have expressed here). I wouldn't be surprised that if
+GNAT were to unimplement it (which I am *not* proposing!), that they would find
+no one is using it.
+
+It seems clear to me that GNAT does what is easiest to implement, which is what
+happens when an implementor defines capabilities. That is not necessarily the
+best thing for users, or even for other implementors. It would be a bad idea to
+adopt these very pragmatic definitions blindly, just as it is a bad idea to
+diverge too much from what works.
+
+----
+
+You want to talk about stubborn, I'll give you stubborn. I've been trying to
+build a reasonable consensus on this topic, but I am beginning to think that the
+effort has been wasted. I'm going to write up a reasonable proposal, and them
+I'm going to fight at every level to adopt it. And I don't want to talk about
+this anymore until I've had time to properly write up that proposal.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Saturday, March 18, 2000 7:49 AM
+
+<<An Unsuppress overrides any outer or preceding Suppress only, including
+Suppress...On. An inner Suppress still can suppress checks, even if there is
+an outer Suppress.
+>>
+
+This is a severe implementation burden for absolutely no useful gain in
+my opinion. It means that the effect of
+
+Suppress (Range_Check);
+Unsuppress (Range_Check);
+
+is not equivalent to nothing, and that means that we need a whole set of
+extra flags to record the presence of the Unsuppress.
+
+And what is this for? Just to deal with the case where someone uses an
+implementation-defined Suppress (.., On=>) and then does an Unsuppress
+in an inner range.
+
+We are making the great mistake here of letting best be the enemy of good.
+And the trouble is that this means we will fail in our goal of improving
+commonality.
+
+If the above spec is adopted, it is quite unlikely in my view that GNAT
+could justify a significant implementation effort of no value to our
+users, just so some weird implementation dependent use of
+Suppress ( .. On=>) is better defined.
+
+Why can't we just back off here and define Unsuppress (X) as undoing
+the effect of Suppress (X) or Suppress (All_Checks) or an equivalent
+compilation option, and say that the handling of the On case is
+implementation dependent (both for Suppress and Unsuppress).
+
+That way we get 99% of the utility of the feature with a minimum of
+hassle.
+
+Personally I think it would be quite reasonable for an Ada 95 compiler
+to completely ignore the Suppress (.., On =>) form, and of course if
+the above spec were adopted, the argument for doing that would be
+even stronger. If we were doing GNAT from scratch right now, probably
+we would do that even without the spec above, and certainly with the
+above spec, it would be crazy to go to a lot of effort. But GNAT is
+out there, and we do not feel like making incompatible changes. Indeed,
+other compilers have probably implemented Suppress (xxx, On=>) to do
+something or other ...
+
+Think of it this way, in any implementation (talking only about the
+general case without ON), Suppress does something, and must be handled
+in a stack like manner so that as you unwind you get back to where
+you want.
+
+Unsuppress merely undoes whatever was done, and can almost certainly
+share the same stack like mechanism. So it is a minimum implementation
+burden.
+
+I must say this whole discussion is an amazing example of how the ARG
+can take something simple, and turn it complex by arguing about marginal
+cases of no interest to the real world. It's bad enough to do that during
+the language design itself, but it really is not acceptable at all in
+trying to do URG type activities.
+
+So, bottom line, here is how I think Unsuppress should be written up.
+
+
+Unsupress (xxx) has the effect of undoing any previous or outer level
+Suppress for the same check (or all checks, or an equivalent
+compiler option). Suppress and Unsuppress stack and unstack (just
+as Suppress does now).
+
+The effect of Unsuppress on a previous or higher level (Suppress, On=>xxx)
+is implementation defined.
+
+The effect of Unsuppress (xxx, On =>xxx) is implementatoin defined.
+
+And while we are at it, it might be nice to point out that
+Suppress (xxx, On=>xxx) is implemenmtation dependent in the first
+place.
+
+For my taste, I would have added a guarantee that
+
+Unsuppress (xxx, On => yyy)
+
+undoes the effect of an identical outer level or previous Suppress, but
+I really don't care if this is in or not. At least it should be
+implementation advice.
+
+--------
+more thoughts:
+
+I have never ever ever seen anyone do a pragma suppress with ON as a
+configuration pragma, in fact I don't think it's legal, since how could
+you have a valid LOCAL_NAME.
+
+So worrying about the effect of Unsuppress on such a Suppress is just way
+outside the original areas of concern for this pragma.
+
+The pragma as simply defined is a really useful feature, attempting to
+fancy it up by over-worrying about the ON case is a way of making it
+much less useful in my opinion.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Saturday, March 18, 2000 8:36 AM
+
+<<I find this entire discussion *extremely* frustrating. People are
+attributing long rejected ideas to me, and then setting them up so Robert
+can use them as an excuse to force us to adopt a very dubious (but easy to
+implement) definition of this pragma.
+>>
+
+OK, look here, I now find he entire ARG work on this of no interest to
+us here at ACT. Please do whatever you like, but please do not expect
+ACT to pay any attention to the result if it requires lots of implementatoin
+effort for no possible gain to our customers.
+
+I am not trying to FORCE anyone to do anything, I am just pointing out the
+reality that as a company we are not going to spend resources on modifying
+a feature that we have had for years and is in a form that is useful just
+because the ARG thinks that some change is useful. Of course useful changes
+are welcome, but the change here is in my opinion damaging.
+
+I would advise however that if the ARG wants to define a feature that is
+incompatble with the existing Unsuppress pragma of GNAT that they kindly
+choose another name to avoid confusion among the large number of Ada 95
+users who are using Unsuppress today. So by all means go back to Force or
+Require or whatever you like.
+
+My point is twofold
+
+1. If the ARG defines Unsuppress, it should be upwards consistent with the
+existing implementation in GNAT.
+
+2. Anything the ARG does here should be easy to implement and generally
+useful.
+
+(and the reason for 2 is that vendors will simply not implement features
+that do not meet these two criteria).
+
+In our opinion here, Randy's formulation of Unsuppress does not meet either
+of the criteria of requirement 2 above.
+
+But I am not trying to force anyone to do anything. Frankly I think the
+work of the ARG on this particular point is rather marginal, especially
+for us, since we already have a perfectly good implementation of this
+feature, which
+
+a) is well defined, and the definition is easy to understand
+
+b) it meets our customers requirements, no one has ever suggested any
+changes or enhancements to this feature.
+
+Really, Randy, to resort to non-technical arguments that I am trying to
+force people to do things is quite inappropriate to this discussion.
+
+Anyway, I will not partipate further in this discussion, so do not expect
+any more notes from me. I think my position (representing the position
+of ACT) is clear at this stage. Others will have to take it from here.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, March 19, 2000 7:54 PM
+
+First of all, let me apologize for any unintentional personal attacks that I may
+have made in my frustration on Friday. I was always taught to attack the ideas,
+not the person, and I always try to follow that in e-mail. If I crossed over
+that invisible line, I am sorry.
+
+Robert suggested:
+
+> Why can't we just back off here and define Unsuppress (X) as undoing
+> the effect of Suppress (X) or Suppress (All_Checks) or an equivalent
+> compilation option, and say that the handling of the On case is
+> implementation dependent (both for Suppress and Unsuppress).
+
+For commonality purposes, I could agree to this (indeed, I was thinking of
+proposing it on Friday). But sooner or later these commonality features are
+going to get added to the standard (unless of course Ada is dead, but then why
+even bother with commonality?). And when they do, I don't think that users of
+Ada, the ones that vote on the new standards, are going to like a feature that
+appears to be 90% implementation-defined. (Even if in practice, it is more like
+10% implementation-defined).
+
+So I would rather get this right now, rather than having to deal with it again
+some years down the road, when even more implementations exist and we may be
+boxed into a corner.
+
+----
+
+Anyway, I think we've gotten beyond the "light" stage of this discussion, so
+it's time to stop discussing it for a while.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Sunday, March 19, 2000 9:31 PM
+
+<<For commonality purposes, I could agree to this (indeed, I was thinking of
+proposing it on Friday). But sooner or later these commonality features are
+going to get added to the standard (unless of course Ada is dead, but then
+why even bother with commonality?). And when they do, I don't think that
+users of Ada, the ones that vote on the new standards, are going to like a
+feature that appears to be 90% implementation-defined. (Even if in practice,
+it is more like 10% implementation-defined).
+>>
+
+Nope, in practice the existing Suppress (On =>) is 90% implementation
+dependent, and it has not bothered anyone.
+
+Getting it "right" can ONLY mean fixing this implementation dependence
+and that is an utter waste of time.
+
+I can't understand why the ARG keeps wanting to waste time on issues that
+have precisely ZERO effect on the Ada user community.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Sunday, March 19, 2000 9:19 PM
+
+Note that my proposal here was completely implementation independent,
+except to the extent that Suppress (... On=>) is implementatoin dependent.
+
+My suggestion is that an Unsuppress of any kind simply cancels a matching
+Suppress in an outer scope, or, if there is no matching Unsuppress in
+an outer scope has no effect.
+
+So Unsuppress (...,On=>) only has effect if there is a corresponding
+Siuppress on the same entity, and has the effect of cancelling it.
+
+This is easy to describe, easy to implement, and means that the only
+level of implementation dependence is what is already there in the language.
+
+This is *exactly* the current GNAT implementation.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 20, 2000 9:55 AM
+
+Robert Dewar wrote:
+> ...
+> This is *exactly* the current GNAT implementation.
+
+I still haven't heard what GNAT does about inheritance from
+spec to body, and from stub to subunit, and how this interacts
+with source-wide [un]suppress configuration pragmas.  That is really
+all I wanted to know when I reignited this firestorm.
+
+Is there someone on the ACT team who could give the details on these
+two topics, and how they interact?
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 20, 2000 10:38 AM
+
+<<I still haven't heard what GNAT does about inheritance from
+spec to body, and from stub to subunit, and how this interacts
+with source-wide [un]suppress configuration pragmas.  That is really
+all I wanted to know when I reignited this firestorm.
+>>
+
+We inherit from spec to body, I am not sure what you mean about
+inheriting from stub to subunit, since a stub cannot contain a pragma???
+
+I also don't quite understand the "source wide" issue.
+
+The configuration pragmas are at the outer level, semantics stack from
+there, perhaps you could give a specific example of what you are asking
+about.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 20, 2000 12:05 PM
+
+Robert Dewar wrote:
+>
+> <<I still haven't heard what GNAT does about inheritance from
+> spec to body, and from stub to subunit, and how this interacts
+> with source-wide [un]suppress configuration pragmas.  That is really
+> all I wanted to know when I reignited this firestorm.
+> >>
+>
+> We inherit from spec to body, I am not sure what you mean about
+> inheriting from stub to subunit, since a stub cannot contain a pragma???
+
+If you have a pragma [un]suppress inside a package body, and then
+there is a stub inside that package body for a separately compiled
+subprogram subunit, presumably the pragma's effects continue into the
+subunit.
+
+>
+> I also don't quite understand the "source wide" issue.
+>
+> The configuration pragmas are at the outer level, semantics stack from
+> there, perhaps you could give a specific example of what you are asking
+> about.
+
+I did give an example in my original mail, but that has been buried under
+a ream of other responses.
+
+Let's take the package spec/body situation.  Suppose inside the package
+spec there is a pragma suppress.  Presumably that is "felt" inside the
+package body as well.  But what about a configuration pragma in the
+file containing the body?  Does that supersede the pragma inherited
+from the package spec (presuming one is a pragma suppress, and the
+other is a pragma unsuppress)?
+
+Another question is whether configuration pragmas in the source file
+containing the package spec are inherited by the package body, even
+though the package body is in a different source file.
+
+Those are the questions I really want answered...
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 20, 2000 12:13 PM
+
+<<Let's take the package spec/body situation.  Suppose inside the package
+spec there is a pragma suppress.  Presumably that is "felt" inside the
+package body as well.  But what about a configuration pragma in the
+file containing the body?  Does that supersede the pragma inherited
+from the package spec (presuming one is a pragma suppress, and the
+other is a pragma unsuppress)?
+>>
+
+The package spec one would override the configuration pragma for both
+the spec and body, this clearly seems what you want in the only case
+where you ever use Unsuppress in practice.
+
+<<Another question is whether configuration pragmas in the source file
+containing the package spec are inherited by the package body, even
+though the package body is in a different source file.
+>>
+
+Yes, they are for GNAT, again that seems to me to be what you want.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, March 20, 2000 12:12 PM
+
+<<If you have a pragma [un]suppress inside a package body, and then
+there is a stub inside that package body for a separately compiled
+subprogram subunit, presumably the pragma's effects continue into the
+subunit.
+>>
+
+Ah, yes, you were not asking from stub to subunit then but rather
+from preceding declarative region to the subunit. Yes of course
+we inherit here, it is clearly required by the RM> Sure you can
+cheat (you can completely ignore suppress for example), but it  is
+clear there is no semantic issue here.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent