CVS difference for ai05s/ai05-0163-1.txt
--- ai05s/ai05-0163-1.txt 2009/11/04 06:26:38 1.3
+++ ai05s/ai05-0163-1.txt 2009/12/06 02:35:02 1.4
@@ -1,4 +1,4 @@
-!standard 2.8(7) 09-10-16 AI05-0163-1/00
+!standard 2.8(7) 09-11-19 AI05-0163-1/01
!class binding interpretation 09-10-16
!status work item 09-10-16
!status received 09-06-28
@@ -9,25 +9,210 @@
!summary
+A sequence_of_statements consisting entirely of pragmas is now allowed.
+
!question
+Should a pragma be allowed in an otherwise-empty sequence_of_statements (that
+is, without adding "null;")? (Yes.)
!wording
+2.8(5-7.1/3) says:
+
+5 Pragmas are only allowed at the following places in a program:
+
+6 * After a semicolon delimiter, but not within a formal_part or
+ discriminant_part.
+7/3 * {AI05-0100-1} At any place where the syntax rules allow a construct
+ defined by a syntactic category whose name ends with "
+ declaration", "statement", "clause", or "alternative", or one of the
+ syntactic categories variant or exception_handler; but not in place of
+ such a construct if the construct is required, or is part of a list
+ that is required to have at least one such construct[, as in a
+ sequence_of_statements].
+
+7.1/3 * {AI05-0100-1} At any place where a compilation_unit is allowed.
+
+We modify 2.8(7.1/3) to remove the "[, as in a sequence_of_statements]" part.
+
+7/3 * {AI05-0100-1} At any place where the syntax rules allow a construct
+ defined by a syntactic category whose name ends with "
+ declaration", "statement", "clause", or "alternative", or one of the
+ syntactic categories variant or exception_handler; but not in place of
+ such a construct if the construct is required, or is part of a list
+ that is required to have at least one such construct.
+
+Add a new paragraph after that:
+
+ * In place of a statement in a sequence_of_statements.
+
+The following Language Design Principles and Implementation Advice are removed:
+
+ Language Design Principles
+
+1.a/3 {AI05-0100-1} In general, if all pragmas are erased from a program,
+ the program should remain both syntactically and semantically legal.
+ There are a few exceptions to this general principle (for example,
+ pragma Import can eliminate the need for a completion), but the
+ principle remains, and is strictly true at the syntactic level.
+ Certainly any implementation-defined pragmas should obey this
+ principle both syntactically and semantically, so that if the
+ pragmas are simply ignored by some other implementation, the program
+ will remain legal.
+
+ Implementation Advice
+
+16 Normally, implementation-defined pragmas should have no semantic effect
+for error-free programs; that is, if the implementation-defined pragmas are
+removed from a working program, the program should still be legal, and should
+still have the same semantics.
+
+16.a.1/2 Implementation Advice: Implementation-defined pragmas should have
+ no semantic effect for error-free programs.
+
+16.a Ramification: Note that "semantics" is not the same as "effect;" as
+ explained in 1.1.3, the semantics defines a set of possible effects.
+
+16.b Note that adding a pragma to a program might cause an error (either
+ at compile time or at run time). On the other hand, if the
+ language-specified semantics for a feature are in part
+ implementation defined, it makes sense to support pragmas that
+ control the feature, and that have real semantics; thus, this
+ paragraph is merely a recommendation.
+
+17 Normally, an implementation should not define pragmas that can make an
+illegal program legal, except as follows:
+
+18 * A pragma used to complete a declaration, such as a pragma Import;
+
+19 * A pragma used to configure the environment by adding, removing, or
+ replacing library_items.
+
+19.a.1/2 Implementation Advice: Implementation-defined pragmas should not
+ make an illegal program legal, unless they complete a declaration or
+ configure the library_items in an environment.
+
+19.a Ramification: For example, it is OK to support Interface,
+ System_Name, Storage_Unit, and Memory_Size pragmas for upward
+ compatibility reasons, even though all of these pragmas can make an
+ illegal program legal. (The latter three can affect legality in a
+ rather subtle way: They affect the value of named numbers in System,
+ and can therefore affect the legality in cases where static
+ expressions are required.)
+
+19.b On the other hand, adding implementation-defined pragmas to a legal
+ program can make it illegal. For example, a common kind of
+ implementation-defined pragma is one that promises some property
+ that allows more efficient code to be generated. If the promise is a
+ lie, it is best if the user gets an error message.
+
!discussion
+
+It is annoying that one cannot write things like:
-Lots of griping about AI05-0100-1 in the e-mail; see !appendix. Ed wanted an
-AI; your editor wanted to put the thread in the bit-bucket. He's not wasting
-time on an AI write-up.
-
-If the idea about allowing pragmas in parameter lists is pursued, we'll need
-to figure out the effect on conformance (and make sure the conformance rules
-actually allow what is decided).
+ if ... then
+ pragma Assert (...);
+ else
+ ...
+
+Instead, one must insert "null;" either before or after the pragma.
+
+This AI allows the above without the "null;", because (1) we don't believe it
+aids readability in any way, and (2) the property of removing pragmas and
+retaining syntactic legality is of no practical value. Removing pragmas,
+whether language-defined or implementation-defined, can already have a radical
+effect on the run-time behavior of the program, so retaining legality is
+pointless. In fact, it is damaging, for the usual reasons that compile-time
+errors are preferable to run-time or totally-undetected errors.
+
+Note that the wording "In place of a statement in a sequence_of_statements." (as
+opposed to "In place of a sequence_of_statements.") makes it clear that two or
+more pragmas are allowed.
+Note that we choose not to take the next logical step of allowing an entirely
+empty sequence_of_statements:
+
+ if ... then
+ -- Syntax ERROR!
+ else
+ ...
+
+because many people find the extra "null;" to aid readability in that case.
+
+Note that we do not propose to allow pragmas in place of other things where it
+might make sense. For example, at least one component, or "null;" is required
+in a component_list, so the following remains illegal:
+
+ type T is
+ record
+ pragma Page; -- Syntax ERROR!
+ end record;
+
+because it's too much trouble to craft the wording, and not much use. The
+reason it's a lot of trouble is that there are cases where it would not make
+sense to allow pragmas "in place of", so we can't just remove the "not in place
+of" wording overall. For example, in:
+
+ select
+ pragma Page;
+ delay 0.001;
+ pragma Page;
+ then abort
+ ...
+ end select;
+
+we really need to have a triggering_alternative, or it wouldn't make sense at
+run time.
+
+We considered allowing pragmas in formal_parts of procedures and the like.
+However that was considered to complicated. For example, we're not sure how it
+would affect the conformance rules.
+
+Finally, all the verbiage that attempts to define what pragmas are "in good
+taste" is removed. This AI makes such wording blatantly wrong -- removing the
+pragma Assert in the first example above makes the program syntactically
+illegal. It makes no sense to talk about semantic legality if we don't even
+have syntactic legality.
+
+In any case, the "good taste" principles/advice are so full of exceptions that
+it is clear they don't really mean much. We don't want to add more verbiage
+that has no practical effect -- most implementations are known to disobey the
+"good taste" principles/advice, and aren't about to change. Such
+implementations can even claim to conform to the Advice, because it says
+"Normally,...", and an implementation can reasonably say, "Well, this particular
+pragma is not a normal one, and for good reason."
+
+Historical note: In Ada 83, implementation-defined pragmas were forbidden to
+affect legality in either direction. The intent in Ada 95 was to weaken this
+rule to only forbid pragmas that make an otherwise-illegal program legal, and to
+add the "Normally, ..." loophole. We now remove all the "good taste"
+principles/advice, and leave matters of taste up to implementers.
+
+Note that this makes pragmas more similar to attributes -- implementations are
+allowed to have non-standard attributes, and removing them can certainly make
+programs illegal.
+
+Note that we retain the Requirement of a warning on unrecognized pragmas.
+
+We considered rewriting the BNF syntax rules to show precisely where pragmas are
+allowed. This would be clearer than the English-language description, which has
+already been subject to some AIs. However, this idea was considered too
+difficult, and was rejected. Some 100 BNF rules would need to be carefully
+inspected (all the ones endind in "declaration", "statement", etc), so this
+change was considered too error prone.
+
+It is a pleasure to write up an AI that REDUCES the size of the RM!
+
!ACATS Test
+An ACATS C test is needed, to test the newly-allowed syntax.
+Existing B tests that use the newly-allowed syntax will need to be modified or
+removed from the test suite.
+
+
!appendix
From: Robert Dewar
@@ -547,7 +732,8 @@
> there is no point, then they should simply have been deleted or
> simplified down to "anywhere that a semicolon is allowed". Once we
> understood the intent, it seemed important to document it so we
-> wouldn't have to argue about what these complex rules are supposed to be doing.
+> wouldn't have to argue about what these complex rules are supposed to be
+> doing.
It is indeed annoying that pragmas can't be put anywhere
@@ -881,7 +1067,8 @@
> implementers are going to do whatever they want in any case), but in
> another sense, guidance for the design of these things does seem
> valuable if it increases the possibility of portability. Seems worth
-> discussing further (although Bob better show up if he wants a different result than the last time :-).
+> discussing further (although Bob better show up if he wants a different result
+> than the last time :-).
I don't think that guidance will have any effect whatsoever on implementors, who
will be guided by customer needs, not the ARG in this respect.
@@ -923,5 +1110,504 @@
> own procedures! ^^
Is it the origin of the name RR Software?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, November 19, 2009 12:52 PM
+
+Here's a new version of AI05-0163-1 [this is version /01 - ED], which allows a
+sequence_of_statements to consist entirely of pragma(s), with no "null;"
+required, as agreed at the ARG meeting. Also, as agreed, it does not propose to
+allow pragmas in procedure specs.
+
+A possibly-controversial aspect is that I removed all the stuff from the RM and
+AARM about "good taste in pragmas". I just couldn't see how to reword it to
+make sense with the new rule. I know Tucker has some fondness for this
+verbiage, so might want to argue against this change.
+
+Let me point out the history (as I see it, of course):
+
+Ada 83 forbade impl-def pragmas from affecting legality.
+There is no sensible reason for this, and I advocated removing it in Ada 9X, but
+instead it was weakened in several ways: only applies in one direction,
+downgraded to Impl Advice, some exceptions added, weasel word "Normally, ..."
+added, which allows implementations to add their own exceptions.
+
+AI-150 added some Language Design Principles in the AARM.
+The idea was that if we're going to have Advice, we need to defend it. But this
+Advice comes originally from Jean Ichbiah (with changes), and I have no idea
+what Ichbiah was thinking. In short I see no need to defend anything, and indeed
+no need for the advice at all.
+
+So Tuck (or anybody else), if you want to argue in favor of having good-taste
+rules of some sort, I suggest you address my rationale below, and also suggest
+wording. The current wording is certainly wrong, given the change made by this
+AI.
+
+Folks should also review my various related decisions mentioned below (no
+changes to records, for ex.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, November 19, 2009 1:26 PM
+
+I guess I do object to removing all this verbiage.
+
+We are just making one special case to allow a pragma to act as a statement.
+That hardly seems enough justification to erase all the advice about
+implementation-defined pragmas. I will make an attempt to fix the existing
+advice to accommodate the special case we are making for statements, and keep an
+eye out for clearly meaningless advice.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 19, 2009 2:37 PM
+
+I strongly object to the pragma good taste rules. I say good riddance!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 19, 2009 2:45 PM
+
+> I guess I do object to removing all this verbiage.
+
+Well I think the advice is pointless. Certainly we pay absolutely zero attention
+to this advice in the case of GNAT, and many of the "bad taste" pragmas we have
+are imported from other implementations, so we are certainly not alone in
+ignoring this advice.
+
+What's the point of stuff in the RM that has no effect whatever on
+implementations?
+
+We have only the following criteria for pragmas
+
+a) they must be conformant to the standard, but we will stretch mightily to
+ follow only the word and not any guessed spirit of any restrictions that
+ stand in our way.
+
+b) they must be useful to our users
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, November 19, 2009 2:50 PM
+
+It seems to be a very important principle that implementors can generally add
+pragmas without necessarily creating portability problems (unlike attributes). I
+think we need to encourage that, and try to provide guidelines for how to
+accomplish it, both for the benefit of users and vendors.
+
+In any case, I don't believe the ARG decided that part of the "intent" of this
+AI was gutting the implementation advice, so we at least need to consider that
+as a group.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 19, 2009 4:53 PM
+
+> It seems to be a very important principle that implementors can
+> generally add pragmas without necessarily creating portability
+> problems (unlike attributes).
+> I think we need to encourage that, and try to provide guidelines for
+> how to accomplish it, both for the benefit of users and vendors.
+
+But in fact I don't think the words in the ARG have ANY effect WHATEVER in
+encourging what you think (but I and others disagree) is good taste in this
+respect.
+
+The fact is that pragmas can indeed cause huge portability problems, even if
+they only affect semantics and not legality, and in any case attributes, as
+noted above, can cause very serious portability problems anyway.
+
+Any user for whom this portability is a concern can avoid the use of
+impl-defined pragmas/attributes and enforce this decision.
+
+For a user and implementor who do NOT care about portability, the RM has no
+useful advice wrt pragmas, so why offer gratuitous useless advice.
+
+I understand the theoretical world in which Tuck is operating his portability
+argument, but it has nothing to do with the real world, and is in any case a
+figure in a dike that is leaking buckets at other points.
+
+> In any case, I don't believe the ARG decided that part of the "intent"
+> of this AI was gutting the implementation advice, so we at least need
+> to consider that as a group.
+
+Indeed, let's see what others think here!
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, November 20, 2009 12:55 AM
+
+> Any user for whom this portability is a concern can avoid the use of
+> impl-defined pragmas/attributes and enforce this decision.
+
+But why restrict yourself to pragmas? You could say the same thing of any
+language extension. "We have implemented full multiple inheritance in Ada,
+people who want portability should avoid using it".
+
+That's exactly what Ada was supposed to avoid: a core language, with many
+extensions, all incompatible between vendors. Remember Ichbiah's fish?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 20, 2009 6:14 AM
+
+> But why restrict yourself to pragmas? You could say the same thing of
+> any language extension. "We have implemented full multiple inheritance
+> in Ada, people who want portability should avoid using it".
+
+Because the language very specifically allows pretty much arbitrary extension as
+long as it is restricted to pragmas and attributes. Any other kind of extension
+would be non-conforming.
+
+> That's exactly what Ada was supposed to avoid: a core language, with
+> many extensions, all incompatible between vendors. Remember Ichbiah's fish?
+
+But the fact is that pragmas and particularly attributes were designed into the
+language as a specific exception to this principle. So there is nothing
+"non-Ada" about allowing implementations to extend the language with pragmas and
+attributes.
+
+The real point here is that having some weasel words about pragmas not affecting
+legality is pointless because:
+
+a) if you have pragmas that radically affect the semantics, e.g. pragma
+ C_Pass_By_Copy which was initially an impl-defined pragma, or pragma
+ Persistent_BSS, or pragma Machine_Attribute, or pragma Thread_Local_Storage,
+ just to pick a few examples from GNAT, these pragmas 100% meet the IA. You
+ can remove them, and the program compiles fine without them, so it compiles
+ fine with some other compiler not recognizing these pragmas. But how does
+ that promote portability? The resulting program has totally wrong semantics
+ if the pragma is involved. So limiting the IA to legality is wholly
+ insufficient.
+
+b) in practice implementations ignore this IA in any case, so the idea that
+ these words have some effect is a language lawyer delusion.
+
+c) in any case attributes are not reigned in this way, and so
+ extension-via-attribute is rampant, and causes even more portability problems
+ than pragmas can cause.
+
+If Ada went all the way and said that pragmas could affect neither legality nor
+behavior, then that would be one thing. Of course it would mean that only the
+most useless of pragmas, like Title, would be allowed, and in practice would
+make Ada less usable. But the Ada design (including JDI with his fish)
+recognized that a well-defined escape hatch for implementation defined additions
+is needed.
+
+Going back to JDI's point, it is of course just fine to add full multiple
+inheritance to any Ada compiler provided it is done under an extension switch.
+For example, GNAT today implements conditional expressions under the -gnatX
+extension switch (shortly to be moved to the -gnat12 flag for Ada 2012). Nothing
+wrong with that, but it's completely outside the language as formally defined.
+
+Now in the case of pragmas and attributes, we don't need a switch.
+The one thing that Ada 83 and Ada 95 missed was the need for a clear way for a
+programmer to say "no impl-defined attributes/pragmas".
+
+GNAT added that capability a long long time ago and finally that got added to
+Ada 2005 (though for some reason, Ada 2005 still missed
+No_Implementation_Restrictions, why?) At the point where
+No_Implementation_Pragmas was added to the language, the vague IA should have
+been dropped. NIP is definitive and forces full portability. It is what you want
+if you are interested in portability. You cannot rely on the RM advice even if
+compilers did follow it, because of the fact that unbounded semantic effects are
+still allowed from pragmas.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 20, 2009 7:04 AM
+
+It is true that implementation-defined attributes create portability problems,
+but it is typically the case that implementation-defined pragmas don't.
+
+This isn't theoretical as far as I am concerned, because on a daily basis we
+compile our 300+KLOC Inspector sources through two different Ada compilers, and
+although AdaMagic warns about many of the GNAT pragmas, the program in fact runs
+identically (as far as testing can determine) with the two compilers.
+
+Clearly someone had some "taste" who designed the GNAT pragmas. ;-) I have less
+confidence in what users might try to torture their Ada vendors into providing.
+
+I certainly don't want to reject programs just because they use a few "tasteful"
+pragmas, and I would rather not have to look in detail at each such pragma to
+decide whether or not it is in fact one of the "tasteful" ones.
+
+In my view, implementations that provide a lot of non-tasteful pragmas are not
+doing the language a favor, and I believe the RM ought to somehow communicate
+that, both to the vendors, and to the users who might try to persuade their
+vendor to create these pragmas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 20, 2009 7:52 AM
+
+> Clearly someone had some "taste" who designed the GNAT pragmas. ;-) I
+> have less confidence in what users might try to torture their Ada
+> vendors into providing.
+
+There are dozens and dozens of GNAT pragmas that violate the RM IA, and also
+many that affect semantics in a fundamental way. After all Inspector doesn't
+care much if the program still does what it is supposed to do, it is about
+finding problems that will indeed mostly be independent of pragmas. Users don't
+have to torture us, we will pretty much provide any pragmas that make technical
+sense, or have been made available in other vendors compilers. Our only
+criterion is whether they make sense from a technical point of view, nothing
+else.
+
+> I certainly don't want to reject programs just because they use a few
+> "tasteful" pragmas, and I would rather not have to look in detail at
+> each such pragma to decide whether or not it is in fact one of the
+> "tasteful" ones.
+
+Well as I say, GNAT pays no attention whatever to the RM advice in this area.
+
+> In my view, implementations that provide a lot of non-tasteful pragmas
+> are not doing the language a favor, and I believe the RM ought to
+> somehow communicate that, both to the vendors, and to the users who
+> might try to persuade their vendor to create these pragmas.
+
+Well GNAT certainly provides lots of pragmas of all kinds, if you think that all
+the GNAT pragmas are in good taste, then for sure I can't imagine what might be
+non-tasteful :-)
+
+If the justification for this language is that it will influence users and
+vendors, that certainly does not apply for GNAT. Does it apply for other
+compilers, e.g. will Ada Magic suddenly go berserk adding pragmas if we remove
+this implementation advice? I doubt it!
+
+Actually, the provision of full preprocessing facilities is much more radical
+than any pragmas, and most Ada compilers provide this capability (don't know
+about Ada Magic, though people can always use e.g. the C preprocessor at a
+pinch).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 20, 2009 8:35 AM
+
+> There are dozens and dozens of GNAT pragmas that violate the RM IA,
+> and also many that affect semantics in a fundamental way. After all
+> Inspector doesn't care much if the program still does what it is
+> supposed to do, it is about finding problems that will indeed mostly
+> be independent of pragmas. Users don't have to torture us, we will
+> pretty much provide any pragmas that make technical sense, or have
+> been made available in other vendors compilers. Our only criterion is
+> whether they make sense from a technical point of view, nothing else.
+
+Two things: I am not talking about running the Inspector on other people's
+sources. I am talking about compiling the Inspector itself, which is written in
+Ada.
+
+Secondly, you talk about "makes technical sense" but I think it helps to have
+some guidelines in the RM for that decision. Obviously you disagree, but I will
+say that when I first started using Ada, and first read the reference manual, it
+was very helpful to understand the *intent* behind the pragma capability, and
+how it was supposed to relate to the underlying semantics. Yes you are right
+that vendors can still do whatever they please, but it really helps to
+understand what is the point of the pragma capability, as opposed to, for
+example, the attribute capability, when reading the RM.
+
+Anyway, it doesn't look we are convincing each other, so I'll shut up at this
+point.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 20, 2009 8:48 AM
+
+> Two things: I am not talking about running the Inspector on other
+> people's sources. I am talking about compiling the Inspector itself,
+> which is written in Ada.
+
+OK, but the inspector code was written by chaps with a VERY good sense of what
+pragmas to use while retaining portability. For interest, what are examples of
+impl-defined pragmas you use in the inspector sources (I would have expected the
+answer to be none, but apparently that is not the case).
+
+> Secondly, you talk about "makes technical sense" but I think it helps
+> to have some guidelines in the RM for that decision.
+
+Well I have designed many of the pragmas for GNAT, and I always thought the
+attempt in the RM to limit things was useless (remember my VERY early example of
+pragma Fortran, which says roughly: all programs are erroneous, and if you want
+to ask what happens if they are exected, the effect is to compile the comments
+as fortran code and execute the result. Pragma Fortran is 100% conforming with
+the severe restrictions in Ada 83 on pragmas.
+
+It is not that I disagree that some level of good taste must reign in pragma
+design. Obviously I would strongly disapprove of pragma Fortran as described
+above. Indeed I thought DEC went too far in some of their pragma stuff. (and now
+of course we have to copy that). My point is that I don't believe the RM is any
+help in formulating the good taste.
+
+In fact I think it is damaging. If you formulate a set of rules, then there is a
+tedency to think that this gives a license for anything that follows the letter
+of these rules (*), including pragma Fortran.
+
+So I agree with your goals in reigning in pragmas and keeping them in good
+taste. It is just that I think the RM language approach is at best useless, and
+at worst actively harmful in achieving that goal.
+
+(*) sort of like the extra payment for carbon offset when buying airline
+tickets. Environmentalists have come to oppose this. Why? Because they want
+people to fly less and generate less CO2. The carbon offsets may neutralize
+guilt, and thus give people implicit permission to fly more :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 20, 2009 8:53 AM
+
+> I certainly don't want to reject programs just because they use a few
+> "tasteful" pragmas, and I would rather not have to look in detail at
+> each such pragma to decide whether or not it is in fact one of the
+> "tasteful" ones.
+
+I understand the "would rather not..." but, in fact, that's exactly what was
+necessary. You and I specifically discussed pragma Abort_Defer[*], which is
+GNAT specific, and we decided not to use it. We used protected objects and
+finalization ops for our abort-deferred regions instead. The alternative would
+have been to add that pragma to Ada Magic.
+
+The point is: we didn't rely on any Impl Advice; we had to understand the
+semantics of each impl-def pragma we considered using.
+
+[*] Or is it Defer_Abort? -- I can never remember the name.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 20, 2009 9:01 AM
+
+Abort_Defer .. I find the omission of this capability from Ada puzzling. It is
+hard enough to write abort-safe code *with* this pragma, and *really* hard
+without it!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 20, 2009 9:03 AM
+
+> In any case, I don't believe the ARG decided that part of the "intent"
+> of this AI was gutting the implementation advice, so we at least need
+> to consider that as a group.
+
+Agreed -- I had no mandate to remove that Advice. I just noticed that the
+current Advice is clearly incompatible with "pragmas in place of null", and I
+tried to rewrite it, and it got more and more complicated, and more and more
+obviously-pointless. We've moved over the years from "Thou shalt not do X" to
+"Thou shalt not do X, except foo, and except bar, and except blah, and anyway we
+don't really mean it." The "pragmas in place of null" thing is one more
+"except...".
+
+Note that we still have the rule that if an implementation doesn't recognize a
+given pragma name, the pragma has no effect (except a warning). Nobody suggests
+changing that. I would think that would satisfy your portability-related
+desire. It's just the notion of textually erasing pragmas from the program that
+doesn't work, and that's the part I propose to remove.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 20, 2009 9:06 AM
+
+> I will make an attempt to fix the existing advice to accommodate the
+> special case we are making for statements, and keep an eye out for
+> clearly meaningless advice.
+
+OK.
+
+But I think you also owe us specific rebuttals to the rationale I gave in the
+proposed AI. Otherwise, we're just talking past one another. "Portability is
+good." "Yeah, but the Advice doesn't provide portability." "Yeah, but
+portability is good, and it's like an Ichbiah Fish." "Yeah, but..." etc.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 20, 2009 8:54 AM
+
+> Remember Ichbiah's fish?
+
+What's that?
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, November 20, 2009 9:08 AM
+
+Ichbiah used to describe extension to programming languages as fish food, put in
+a bottle in the water. The little fish enters the bottle, eats all the nice
+food, becomes a bigger fish, and cannot exit any more.
+
+I.e.: when you start to depend on nice extensions, you end up bound to a single
+compiler vendor.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 20, 2009 9:17 AM
+
+> For interest, what are examples of impl-defined pragmas you use in the
+> inspector sources (I would have expected the answer to be none, but
+> apparently that is not the case).
+
+Pragma Warnings was one.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 20, 2009 9:43 AM
+
+Here is a nearly complete list:
+
+Warning: Unrecognized pragma name => "Unmodified"
+Warning: Unrecognized pragma name => "Ada_2005"
+Warning: Unrecognized pragma name => "Finalize_Storage_Only"
+Warning: Unrecognized pragma name => "No_Strict_Aliasing"
+Warning: Unrecognized pragma name => "Style_Checks"
+Warning: Unrecognized pragma name => "Unreferenced"
+Warning: Unrecognized pragma name => "Unreserve_All_Interrupts"
+
+We actually "recognize" and ignore pragma Warnings... ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 21, 2009 9:52 AM
+
+An interesting set. Ada_2005 does of course affect legality, but in a rather
+predictable way (I wonder whether this is a pragma that should be standardized).
+
+Unmodified, Style_Checks, Unreferenced, Warnings are certainly "in good taste"
+OK pragmas, but probably not ones to consider standardized.
+
+Unreserve_All_Interrupts does definitely affect behavior, but at a level really
+outside the RM.
+
+Finalize_Storage_Only is just an optimization pragma, so again in "good taste".
+
+No_Strict_Aliasing causes the behavior of erroneous programs to become
+well-defined (the case is when conversion of access types with unchecked
+conversion results in an erroneous situation because a pointer has a value
+which strictly speaking is illegitimate, but we "know what we mean". This
+situation is 100% analogous to the conversion of pointers in C, which is also
+undefined by the C standard, but frequently used.
+
+One thing this discussion suggests is that useful documentation for GNAT or any
+other compiler would be a discussion of how the impl-defined pragmas affect
+portability in practice. I will open an enhancement ticket for GNAT to work on
+this one day.
****************************************************************
Questions? Ask the ACAA Technical Agent