!standard 2.8(7) 09-10-16 AI05-0163-1/00 !class binding interpretation 09-10-16 !status work item 09-10-16 !status received 09-06-28 !priority Low !difficulty Medium !qualifier Omission !subject Pragmas in place of null !summary !question !wording !discussion 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). !ACATS Test !appendix From: Robert Dewar Sent: Saturday, June 27, 2009 6:50 PM [Split from a thread found in AI05-0135-1 - Editor] > As a pragma, I agree with Brad, simply because this pragma would > violate "good taste in pragmas". We recently added some discussion to > the AARM to explain what good taste is (see 2.8(1.a/3) or AI05-0100-1 > if you don't have the draft 7 AARM handy). In particular, removing a > pragma from a legal program should not make the program illegal This really isn't vaguely true for existing pragmas! For example, removing pragma Pack often makes a program illegal. Removing a pragma Import almost certainly makes a program illegal. Removing a pragma Convention can easily make a program illegal Removing a pragma Pure, Preelaborate, or any of the other categorization pragmas can make a program illegal. Removing a pragma Elaborate can make a program illegal same of course with Elaborate_All and Elaborate_Body. Removing a pragma Atomic or Volatile can make a program illegal. There aren't that many pragmas defined in the RM, and as we see many of them are in "bad taste" :-) Once we have done such a bad job of following our own bad taste rules, I can hardly get upset at adding one more. And since the language is so free in adding these bad taste pragmas (note that most of these were added in Ada 95), I see no reason for implementors to feel bound to stricter standards. I guess to me, it is MUCH worse when removing a pragma can cause the progam to become erroneous, or malfunction in mysterious ways. Ilegality is a nice outcome of improperly removing a pragma compared to these alternatives! Notionally if an implementation has only "good taste" pragmas, then you can remove them all or ignore them all, and the program is still legal. But so what? Pragmas are not there for amusement purposes, almost certainly they are important to the correct functioning of the program. If you have a GNAT program that uses pragma Weak_External, sure you can remove it and the compiler will consider the program legal, but good luck at link time :-) And if you remove a pragma Wide_Character_Encoding, it will be quite surprising if you can still compile your source :-) **************************************************************** From: Brad Moore Sent: Sunday, June 28, 2009 1:04 AM > Once we have done such a bad job of following our own bad taste rules, > I can hardly get upset at adding one more. Good point! Perhaps we should change the labels on the scale in the AARM from "good taste" to "slightly-off taste", where good taste is the ideal that we'd like to strive towards, but seldom achieve in practice. :-) Pragma Page comes to mind as one of the "good taste" pragmas. It tastes good because it doesn't do much. I do think however, that the level of taste drops below "slightly-off" when removing a pragma does not cause any issues locally for the unit that contains the pragma, but causes illegality in other units that may be somewhere far away, possibly in other applications. Pragma Import does not fall into this category, but pragmas such as Pure and Elaborate do - so we would not be breaking new ground in depths of bad taste. :-) **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 1:46 AM Note that in my list of bad taste examples, the "somewhere far away" effect can happen for all these examples except pragma Import, that's the only one where the illegality is bound to be local. **************************************************************** From: Tucker Taft Sent: Sunday, June 28, 2009 8:54 AM I agree with Randy that we should avoid using pragmas that make things legal that would otherwise be illegal (ignoring representational issues). Yes we have some such pragmas now, but there are few, and it was back in Ada 9X that we established this principle and did our best to stick with it. I don't like to see us slipping backwards now. **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 9:18 AM > I agree with Randy that we should avoid using pragmas that make things > legal that would otherwise be illegal (ignoring representational > issues). > Yes we have some such pragmas now, but there are few, and it was back > in Ada 9X that we established this principle and did our best to stick > with it. I don't buy that rewriting of history. Look at my list of problematic pragmas, nearly all of them were introduced in Ada 95 (I think all, given that we got rid of pragma interface, and you are somewhat arbitrarily excluding representation pragmas). > I don't like to see us slipping backwards now. We never went forwards on this issue! **************************************************************** From: Tucker Taft Sent: Sunday, June 28, 2009 10:30 AM I'm not rewriting history by saying that we established the principle. Actually, Bob Duff was the first to voice the principle in my memory, and it was pretty early in the 9X process when we were debating things like passive tasks, etc. You are pointing out that we failed miserably on following our principle, and that is true in the area of conventions, where there are a number of cases that require exact matching of conventions, and that can only be done using pragmas. But I really see representational issues as a separate domain from non-representation-related legality rules. Perhaps that is my own quirk... **************************************************************** From: Bob Duff Sent: Sunday, June 28, 2009 11:22 AM > That's not really true for language-defined pragmas. Pragma Import is > a pragma in bad taste, but it's pretty much impossible to avoid using > it (as much as I'd like to). Imagine trying to write Claw without > using pragma Import! :-) I do not agree that pragma Import is in bad taste. And if I wanted to add some functionality similar to pragma Import, but slightly different in some way, an implementation-defined pragma with similar properties would make sense to me. If you erase all the pragmas from your program, your program is likely to break. This is true for some language-defined pragmas (e.g. Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's pragmas Abort_Defer, Ada_2005, Common_Object). The idea that the broken program should remain legal is utterly pointless. AI05-0100-1 was supposed to fix some confusing wording about pragma placement syntax. Adding the AARM annotation as part of that AI was just plain wrong, and if I'd been paying attention, I would have objected. Luckily, AARM annotations are non-normative, and all implementers will ignore this one -- no sane compiler writer is going remove existing pragmas that violate this "taste" rule, including the compiler writer who wrote that AI (which I'm guessing is our good friend Tucker Taft, based on the style in which the !discussion is written ;-)). **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 11:20 AM > I'm not rewriting history by saying that we established the principle. > Actually, Bob Duff was the first to voice the principle in my memory, > and it was pretty early in the 9X process when we were debating things > like passive tasks, etc. > > You are pointing out that we failed miserably on following our > principle, and that is true in the area of conventions, where there > are a number of cases that require exact matching of conventions, and > that can only be done using pragmas. > > But I really see representational > issues as a separate domain from > non-representation-related legality rules. > Perhaps that is my own quirk... But what about preelaborate, pure etc. These are not representation issues, and removing a pragma here is particularly bad since it causes non-local illegalities. Something that could not happen in Ada 83 pragmas except for representation issues. When I say it's bad, I mean bad by this arbitrary good taste rule. I don't think it's a good rule anyway, and I see no good motivation for it :-) All I am saying is that we should not let future language design be over-influenced by this dubious principle which we have never followed in the past :-) **************************************************************** From: Bob Duff Sent: Sunday, June 28, 2009 11:22 AM > I'm not rewriting history by saying that we established the principle. > Actually, Bob Duff was the first to voice the principle in my memory, > and it was pretty early in the 9X process when we were debating things > like passive tasks, etc. Hmm. One of us is misremembering. The way I remember it, I was strongly against documenting any "good taste" rules for pragmas, because my versions of such rules are way too vague, and have way too many exceptions that I can't explain in any logical way. I find pragma Elaborate to be in poor taste. Pragma Import, not so much. I see nothing wrong with: procedure Check_Goodness (X : T) is begin pragma Assert (); end Check_Goodness; which is illegal. > You are pointing out that we failed miserably on following our > principle, and that is true in the area of conventions, where there > are a number of cases that require exact matching of conventions, and > that can only be done using pragmas. > > But I really see representational > issues as a separate domain from > non-representation-related legality rules. > Perhaps that is my own quirk... I agree with you about representation pragmas. I see a conceptual (ill-defined) distinction between high-level semantics and low-level semantics, and I'm more likely to cry "poor taste" when high-level semantics are affected in such a way that removing a pragma breaks things. Rep pragmas affect low-level semantics. **************************************************************** From: Tucker Taft Sent: Sunday, June 28, 2009 12:47 PM The "Mapping Specification" from 1991 said, roughly: An implementation-defined pragma cannot make an illegal program legal. I think we ultimately dropped that to allow implementation-defined versions of pragma Import, but the principle was there pretty early. And I believe we agreed that language-defined pragmas should only rarely violate the above. But my memory is certainly flaky enough to be mis-remembering who first voiced concerns about "taste" in pragmas. **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 1:12 PM it would have been a HORRIBLE restriction. To say that pragma Ada_2005 is illegal is VERY unhelpful, there are many other examples! You would have forced all kinds of things that are naturally configuration pragmas to be compiler switches instead. Another example is Wide_Character_Encoding. And if you did not make an exception for representation pragmas, that would have been even worse. Anyway, this bad idea did not survive, so no real point in taking pot shots at it now, unless it surfaces to prevent choosing the best design in current discussions. I think we should choose between a pragma and syntax based on the particular case, without reference to this bogus good-taste principle :-) **************************************************************** From: Bob Duff Sent: Sunday, June 28, 2009 1:35 PM > The "Mapping Specification" from 1991 said, roughly: > > An implementation-defined pragma cannot > make an illegal program legal. > > I think we ultimately dropped that to allow implementation-defined > versions of pragma Import, but the principle was there pretty early. > > And I believe we agreed that language-defined pragmas should only > rarely violate the above. > But my memory is certainly flaky enough to be mis-remembering who > first voiced concerns about "taste" in pragmas. Well, my memory could be wrong, too. But it's interesting that I joined the project in July, 1991. I think I had something to do with getting rid of that as a rule, and making it a piece of folklore that is often, but not always, true. ;-) **************************************************************** From: Bob Duff Sent: Sunday, June 28, 2009 1:48 PM Now I remember more: The statement above quoted from the Mapping Spec was a deliberate backing off from the Ada 83 rule, which was that an impl-def pragma cannot affect the legality in either direction. We wanted to allow things like pragma Restrictions, whose (legitimate) purpose is to make legal programs illegal. Then we backed off even further by removing the rule altogether. Part of the argument was that any rules that attempt to limit implementation-defined stuff (including pragmas) are formally nonsensical and unenforcable, because the implementer can always say, "Oh, pragma Legalize_Fortran_Syntax is not an impl-def Ada pragma -- it's only allowed in some nonstandard mode (perhaps the default mode) which is not Ada, but merely Ada-like". **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 11:44 AM > I do not agree that pragma Import is in bad taste. And if I wanted to > add some functionality similar to pragma Import, but slightly > different in some way, an implementation-defined pragma with similar > properties would make sense to me. Such as Import_Procedure and all the other "DEC" pragmas :-) > If you erase all the pragmas from your program, your program is likely > to break. This is true for some language-defined pragmas (e.g. > Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's > pragmas Abort_Defer, Ada_2005, Common_Object). The idea that the > broken program should remain legal is utterly pointless. Actually, I would enunciate the following principle: If you remove a pragma that will cause the program to misbehave, then it is highly desirable that this show up as an illegality. After all if we had some junk syntax to replace pragma Import import x with c (name); or some such, then removing this would be exactly equivalent to removing the pragma, so what's the point in creating some big distinction. **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 11:47 AM > If you erase all the pragmas from your program, your program is likely > to break. This is true for some language-defined pragmas (e.g. > Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's > pragmas Abort_Defer, Ada_2005, Common_Object). The idea that the > broken program should remain legal is utterly pointless. Well removing Ada_2005 presumably causes an illegality (so I am supposed to conclude this pragma is in bad taste???) But Abort_Defer is a really good example. Removing this has VERY subtle effects. If anything it is implementation pragmas that do NOT violate the rule about illegality on removal that are worrisome! **************************************************************** From: Robert Dewar Sent: Sunday, June 28, 2009 11:51 AM One little change I would REALLY like to see in pragmas is that they could stand alone in a statement sequence. It is really annoying having to write junk null statements. if cond then pragma Assert (bla bla) else bla bla end if; should be legal. I see no downside in this, and it would clean up code. **************************************************************** From: Randy Brukardt Sent: Monday, June 29, 2009 9:30 PM > > That's not really true for language-defined pragmas. Pragma Import > > is a pragma in bad taste, but it's pretty much impossible to avoid > > using it (as much as I'd like to). Imagine trying to write Claw > > without using pragma Import! :-) > > I do not agree that pragma Import is in bad taste. And if I wanted to > add some functionality similar to pragma Import, but slightly > different in some way, an implementation-defined pragma with similar > properties would make sense to me. I dislike all representation pragmas on general principles: representation is too important a detail to hide away far away from a declaration. [I don't much like the attribute definition clauses, either for the same reason.] But that's pretty much irrelevant here. > If you erase all the pragmas from your program, your program is likely > to break. This is true for some language-defined pragmas (e.g. > Import, Elaborate_All), and for some impl-def pragmas (e.g. GNAT's > pragmas Abort_Defer, Ada_2005, Common_Object). The idea that the > broken program should remain legal is utterly pointless. I disagree. There is a strong point for "good taste" in implementation-defined pragmas: it allows the code to remain portable even if some other compiler doesn't recognize some impl-def pragma. I've always presumed that this was the intent behind the idea of "good taste". After all, impl-def pragmas that change the legality or correctness of a program are just as bad for vendor lock-in as adding private syntax. I'm sure that in the Ada 83 days such pragmas would have been considered very bad: I know we avoided such things because it wasn't clear to us whether the ACVC statement of conformance allowed impl-def pragmas of that kind. Obviously, we've moved away from that level of portability. As a practical matter, we may not have had any choice. (Implementers need *some* way to describe target-specific features.) But that makes me worry about the future of Ada (if it isn't reasonably portable, it has lost one of its most important advantages). > AI05-0100-1 was supposed to fix some confusing wording about pragma > placement syntax. Adding the AARM annotation as part of that AI was > just plain wrong, and if I'd been paying attention, I would have > objected. Luckily, AARM annotations are non-normative, and all > implementers will ignore this one > -- no sane compiler writer is going remove existing pragmas that > violate this "taste" > rule, including the compiler writer who wrote that AI (which I'm > guessing is our good friend Tucker Taft, based on the style in which > the !discussion is written ;-)). We needed to understand the point of the pragma placement rules. If 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. Of course, had you come to the meeting, you might have convinced us to drop the intent. But then I have no idea what the point of the placement rules is: we surely would have needed an alternative intent. (After all, in early Janus/Ada, pragmas were purely lexical and only supported simple id or literal arguments -- they were removed by the lexer and the parser never saw them. Pragmas could literally appear anywhere, and it worked fine. But we eventually had to change it to support those placement rules and to support complex expressions as pragma arguments -- because the language required that. I've never seen any advantages whatsoever to those more complex pragmas over proper syntax for specifying things.) So if you want some other intent, I think it would be important for you to explain that intent in detail. I can't see any way to determine if the placement rules are right without having *some* intent for the placement and use of pragmas. P.S. Are you and Robert calling for the reopening of AI05-0100-1? **************************************************************** From: Robert Dewar Sent: Tuesday, June 30, 2009 6:52 AM > I dislike all representation pragmas on general principles: > representation is too important a detail to hide away far away from a > declaration. [I don't much like the attribute definition clauses, > either for the same reason.] But that's pretty much irrelevant here. I disagree .. whether representation details are or are not part of the visible interface is a choice up to the designer of the interface. For example type R is bla bla bla private rep clauses to make R efficient for the internal implementation of the package This is a useful and legitimate arrangement, you are saying that the client should NOT depend on the representation of R in this example, and that the implementor may change the representation expecting NOT to break clients. Very useful, we do this all the time > I disagree. There is a strong point for "good taste" in > implementation-defined pragmas: it allows the code to remain portable > even if some other compiler doesn't recognize some impl-def pragma. > I've always presumed that this was the intent behind the idea of "good > taste". After all, impl-def pragmas that change the legality or > correctness of a program are just as bad for vendor lock-in as adding private syntax. Well the design has something to say about legaitly, but NOTHING AT ALL to say about correctness. It is quite deliberate > I'm sure that in the Ada 83 days such pragmas would have been > considered very bad: I know we avoided such things because it wasn't > clear to us whether the ACVC statement of conformance allowed impl-def > pragmas of that kind. With respect to legality, perhaps, but with respect to changed behavior certainly there was NO indication that such pragmas were undesirable, so if you think the language should have discouraged such usage, fine, but you are not talking about Ada as developed. > Obviously, we've moved away from that level of portability. As a > practical matter, we may not have had any choice. (Implementers need > *some* way to describe target-specific features.) But that makes me > worry about the future of Ada (if it isn't reasonably portable, it has > lost one of its most important advantages). It *is* reasonably portable. for one thing, implementors copy one anothers pragmas and attributes (don't forget that attributes are in the same boat here, and they immediately make things illegal if not implemented, there is no rule for ignoring implementaiton dependent attributes, same with restrictions and check names etc etc. > We needed to understand the point of the pragma placement rules. If > 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. It is indeed annoying that pragmas can't be put anywhere > Of course, had you come to the meeting, you might have convinced us to > drop the intent. But then I have no idea what the point of the > placement rules > is: we surely would have needed an alternative intent. (After all, in > early Janus/Ada, pragmas were purely lexical and only supported simple > id or literal arguments -- they were removed by the lexer and the > parser never saw them. Pragmas could literally appear anywhere, and it > worked fine. But we eventually had to change it to support those > placement rules and to support complex expressions as pragma arguments > -- because the language required that. I've never seen any advantages > whatsoever to those more complex pragmas over proper syntax for > specifying things.) I find this point of view amazing, and totally impractical. I can't imagine that a compiler with such a limited view of pragmas could be useful in practice in the Ada world. We support 170 pragmas, the majority of which are implementation dependent, and in fact I would guess that about half of them are copied from other compilers (actually in Ada 2005, fewer are ID, since several have been copied by the standard :-) They are an important part of the usability of the language, and the language design recognizes and expects this by allowing the addition of pragmas. All compilers that we see in the market place implement a rich set of pragmas, so it seems a retrograde argument to argue against this. > So if you want some other intent, I think it would be important for > you to explain that intent in detail. I can't see any way to determine > if the placement rules are right without having *some* intent for the > placement and use of pragmas. I agree that the placement rules are junk. In particular, not allowing pragmas in subprogram parameter lists is a real pain. > P.S. Are you and Robert calling for the reopening of AI05-0100-1? yes, I think that would be a good idea **************************************************************** From: Randy Brukardt Sent: Monday, June 30, 2009 1:50 PM > They are an important part of the usability of the language, and the > language design recognizes and expects this by allowing the addition > of pragmas. All compilers that we see in the market place implement a > rich set of pragmas, so it seems a retrograde argument to argue > against this. Well, this sort of effect is predictable, given that the language doesn't have any other way to create implementation-defined stuff. I personally don't think that had to be the case (and that it would have been better if it was not the case), but in any event it *is* the case and surely it is not going to change. The real question is what, if anything, should be recommended for the design and use of pragmas. In one sense, it doesn't matter (because 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 :-). > > So if you want some other intent, I think it would be important for > > you to explain that intent in detail. I can't see any way to > > determine if the placement rules are right without having *some* > > intent for the placement and use of pragmas. > > I agree that the placement rules are junk. In particular, not allowing > pragmas in subprogram parameter lists is a real pain. Fair enough. > > P.S. Are you and Robert calling for the reopening of AI05-0100-1? > > yes, I think that would be a good idea OK, we need a second. (Two members to move for reconsideration.) **************************************************************** From: Bob Duff Sent: Monday, June 30, 2009 3:39 PM > The real question is what, if anything, should be recommended for the > design and use of pragmas. Nothing. Our job is to define the language, not to give advice about language extensions (including those extensions that are sanctioned by the RM -- pragmas and attributes). >...In one sense, it doesn't matter (because 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. I go with the "one sense", rather than the "'nother sense". I really don't see how anything we say can have any beneficial effect on portability. Implementations copying each others' pragmas can help, as Robert pointed out, but that's different. >...Seems worth discussing further (although Bob better show up if he >wants a different result than the last time :-). Well, I really hate traveling, so I won't make any promises. The chair is allowed to kick me off the committee if he doesn't like that. If I don't show up, I can at least contribute something (hopefully useful) via e-mail. > > > So if you want some other intent, I think it would be important > > > for you to explain that intent in detail. I can't see any way to > > > determine if the placement rules are right without having *some* > > > intent for the placement and use of pragmas. > > > > I agree that the placement rules are junk. In particular, not > > allowing pragmas in subprogram parameter lists is a real pain. > > Fair enough. > > > > P.S. Are you and Robert calling for the reopening of AI05-0100-1? > > > > yes, I think that would be a good idea > > OK, we need a second. (Two members to move for reconsideration.) Well, should I second? I have no objection to the normative part of that AI -- I only object to the AARM wording, and it doesn't have any real effect, since implementations are going to keep supporting whatever pragmas they support (and perhaps add new ones). I thought Robert's Rules said that in order to reconsider, somebody has to change their mind, or something like that. No? **************************************************************** From: Randy Brukardt Sent: Monday, June 30, 2009 4:28 PM > Well, should I second? I have no objection to the normative part of > that AI -- I only object to the AARM wording, and it doesn't have any > real effect, since implementations are going to keep supporting > whatever pragmas they support (and perhaps add new ones). Robert would like to relax the placement rules further (he has given two examples, a pragma in place of "null;", and pragmas in parameter lists. I personally think that if we agree your "no recommendations" recommendation, then we should relax the placement rules some more. I doubt that they are consistently enforced by compilers (there are a bunch of Ada 83 ACATS syntax tests, but I don't think they come close to testing all of the possibilities). (The cases that Robert would like to allow are tested, though.) In any case, whatever the placement rules are, there needs to be justification for them. No justification at all should mean no rules, and I don't think anyone at all is suggesting no rules on the use of pragmas. So I do think that some sort of "language design principle" is needed. If you don't like the one in the AI, then I think you ought to suggest a replacement. (I cannot guess how you think pragmas should work.) > I thought Robert's Rules said that in order to reconsider, somebody > has to change their mind, or something like that. No? My recollection (and looking back at the Venice minutes where this was decided seems to confirm that) was that Tucker pretty much explained how he thought things worked. There was at least some discomfort with the logical result of that, but no one had a better idea (or, as I said in the minutes, perhaps they were afraid that they would end up with the AI if they spoke up - it was treated a lot like a hot potato). So I'm not that convinced that we ended up with a consensus as much as an exhaustion. The net effect is that we may not have ended up with the correct result, and as such I'm willing to look at it again. But only if some strong advocate for some other position steps forward and makes a concrete proposal and (preferably) comes to a meeting to defend it. Otherwise, I would expect we'd come to the same conclusion -- if the only person who seems to care is the same one that drove the result the last time, I think we're likely to come up with the same result. Procedurally, there is no clear way to reconsider a WG 9 approved AI (normally, there should be a request for a letter ballot before it gets to that stage). Our procedures are completely silent on this issue. In the past, we've simply created a new AI to correct the previous one - but that's usually happened because a clear error in the previous one. So that what we ought to do, assuming that there is sufficient support for some alternative *and* Ed concurs (he would be within his rights to keep it off of the agenda based on it having been previously decided). **************************************************************** From: Ed Schonberg Sent: Monday, June 30, 2009 4:52 PM Leaving aside the procedural issue concerning something already WG9 approved, I'm certainly in favor of reopening the discussion (or creating a new AI) to handle those two cases: parameter lists, and null statement lists. It is certainly awkward that we cannot write: else Assert (False); end if; which comes up often enough. **************************************************************** From: Tucker Taft Sent: Monday, June 30, 2009 4:56 PM I would recommend we leave this as is, or make a special exception for statement sequences, allowing a pragma to take the place of a statement, groddy as that may seem. Going much beyond that seems more trouble than it is worth. There are a number of tools, as Randy has said, that essentially ignore pragmas. Of course they can't do full legality checking that way, but they can probably do a fair amount of useful stuff, including overload resolution, cross referencing, style checking, etc. A lot of tools presume the compiler already did all the relevant legality checking, so they just barrel ahead assuming they have a legal program. If some "body" is missing because of some weird implementation-defined pragma that is equivalent to "import," so be it. They can usually survive pretty easily that sort of thing. **************************************************************** From: Bob Duff Sent: Monday, June 30, 2009 5:37 PM > Robert would like to relax the placement rules further (he has given > two examples, a pragma in place of "null;", and pragmas in parameter lists. I think that would require a new AI. AI05-0100-1 didn't address the issue of relaxing the syntax rules -- it just clarified what they are, and added an AARM annotation. The AARM annotation is bogus, IMHO, but relatively harmless. > I personally think that if we agree your "no recommendations" > recommendation, then we should relax the placement rules some more. I could support that. But I could also live with the language as is, even though I agree with Robert's complaints. Shrug. >...I doubt > that they are consistently enforced by compilers (there are a bunch of Ada > 83 ACATS syntax tests, but I don't think they come close to testing >all of the possibilities). (The cases that Robert would like to allow >are tested, though.) I'll bet they are pretty close to "consistently enforced by compilers". > In any case, whatever the placement rules are, there needs to be > justification for them. No justification at all should mean no rules, > and I don't think anyone at all is suggesting no rules on the use of > pragmas. So I do think that some sort of "language design principle" > is needed. If you don't like the one in the AI, then I think you ought > to suggest a replacement. The justification for the current Ada 2005 rules is clear: this is the way it was in Ada 83, and this is the way compilers implemented it. AI05-0100-1 (the normative part, about syntax) matches the _intent_ of Jean Ichbiah, and I see no reason why the ARG should justify his intent in AARM annotations. Even if some guy like Bob Duff comes along and claims that intent was bogus all along. >... (I cannot guess how you think pragmas should work.) I'm not even sure myself. > > I thought Robert's Rules said that in order to reconsider, somebody > > has to change their mind, or something like that. No? > > My recollection (and looking back at the Venice minutes where this was > decided seems to confirm that) was that Tucker pretty much explained > how he thought things worked. There was at least some discomfort with > the logical result of that, but no one had a better idea (or, as I > said in the minutes, perhaps they were afraid that they would end up > with the AI if they spoke up > - it was treated a lot like a hot potato). So I'm not that convinced > that we ended up with a consensus as much as an exhaustion. OK, that convinces me that I do not want to second Robert's motion. I do not want to end up being responsible for [re]writing AI05-0100-1, because it's just not important enough to spend time on. > The net effect is that we may not have ended up with the correct > result, and as such I'm willing to look at it again. But only if some > strong advocate for some other position steps forward and makes a > concrete proposal and > (preferably) comes to a meeting to defend it. I sure ain't flyin' half-way 'round the world to argue about this particular issue! OTOH, if Tuck hosts the meeting at SofCheck, I'll happily go there. >...Otherwise, I would expect we'd > come to the same conclusion -- if the only person who seems to care is >the same one that drove the result the last time, I think we're likely >to come up with the same result. > > Procedurally, there is no clear way to reconsider a WG 9 approved AI > (normally, there should be a request for a letter ballot before it > gets to that stage). Our procedures are completely silent on this > issue. In the past, we've simply created a new AI to correct the > previous one - but that's usually happened because a clear error in > the previous one. So that what we ought to do, assuming that there is > sufficient support for some alternative > *and* Ed concurs (he would be within his rights to keep it off of the > agenda based on it having been previously decided). A new AI is appropriate if someone thinks this issue is important enough. I don't. But I can change my mind. ;-) **************************************************************** From: Robert Dewar Sent: Friday, July 3, 2009 9:06 AM > I would recommend we leave this as is, or make a special exception for > statement sequences, allowing a pragma to take the place of a > statement, groddy as that may seem. I agree with all this, except I don't think it is "groddy" (a rather extreme word, typically meaning "beyond gross"). **************************************************************** From: Robert Dewar Sent: Friday, July 3, 2009 3:00 PM > The real question is what, if anything, should be recommended for the > design and use of pragmas. In one sense, it doesn't matter (because > 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 :-). 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. >>> P.S. Are you and Robert calling for the reopening of AI05-0100-1? >> yes, I think that would be a good idea On second thoughts, if I voted to reopen this, I withdraw my vote, seems a waste of time (except possibly for the groddy rule :-)) **************************************************************** From: Robert Dewar Sent: Friday, July 3, 2009 3:01 PM > I thought Robert's Rules said that in order to reconsider, somebody > has to change their mind, or something like that. No? That's true, but nowhere does it say we are governed by RR, we have our own procedures! **************************************************************** From: Robert Dewar Sent: Friday, July 3, 2009 3:02 PM Why not just make a new AI with the two useful extensions, (parameter list, single statement) and avoid discussions on anything else :-) **************************************************************** From: Jean-Pierre Rosen Sent: Friday, July 3, 2009 5:21 PM >> I thought Robert's Rules said that in order to reconsider, somebody >> has to change their mind, or something like that. No? > > That's true, but nowhere does it say we are governed by RR, we have our > own procedures! ^^ Is it the origin of the name RR Software? ****************************************************************