!standard 2.8(4) 05-10-21 AC95-00115/01 !class Amendment 05-10-21 !status received no action 05-10-21 !status received 05-04-12 !subject !summary !appendix From: Robert Dewar Date: Tuesday, April 12, 2005 1:11 AM RM 2.8(4) says: 4 In a pragma, any pragma_argument_associations without a pragma_ argument_identifier shall precede any associations with a pragma_ argument_identifier. I don't see the purpose of this arbitrary rule, which serves no functional goal. It seems to go half way but no further in drawing tha analogy between pragmas and subprogram calls. I think we should either remove this useless rule, or go all the way and say that if argument identifiers are given, then arguments can be reordered. P.S. GNAT has never checked this rule till last night (I did not even know the rule existed, and would not have anticipated it, since it makes no sense), and that means no one ever had trouble porting, though to be fair, more code gets ported *to* GNAT than *from* GNAT. The AARM provides no enlightenment. The reason I think that we should not retain the status quo is that the current RM wording tends to encourage the common misconception that arguments to pragmas can be reordered (further fueled by the fact that all DEC extra pragmas allow such reordering). **************************************************************** From: Bob Duff Date: Tuesday, April 12, 2005 9:33 AM > The reason I think that we should not retain the status quo is that the current > RM wording tends to encourage the common misconception that arguments to > pragmas can be reordered (further fueled by the fact that all DEC extra > pragmas allow such reordering). I see no value in allowing them to be reordered. If people have that "common misconception", they'll find out soon enough. But I'm biased, in that I don't think subprogram calls should allow reordering, either. Named assocs are supposed to increase readability, and being inconsistent with order doesn't help. I think the reason we didn't allow reordering is that it's easier to write the RM that way. The rules are presented in BNF, and it would either increase the size of the BNF, or require a special rule that says, "never mind what the BNF says; you can reorder". In fact, now that I think about it, doesn't RM 2.8(4) *follow* from the BNF rules? I wouldn't mind allowing mixed named/positional, if this were 1992, but at this point, I think: not sufficiently broken to bother fixing. **************************************************************** From: Randy Brukardt Date: Tuesday, April 12, 2005 12:55 PM > I think we should either remove this useless rule, or go all the way and > say that if argument identifiers are given, then arguments can be > reordered. AI-36 says that pragmas work like subprogram calls. This matters for pragma Import and Export, which have optional arguments. And reordering is not allowed. > P.S. GNAT has never checked this rule till last night (I did not even know > the rule existed, and would not have anticipated it, since it makes no sense), > and that means no one ever had trouble porting, though to be fair, more code > gets ported *to* GNAT than *from* GNAT. > > The AARM provides no enlightenment. It does a bit in B.1(51.b), but of course that's in the newest AARM that hasn't even been posted yet. So nevermind. :-) > The reason I think that we should not retain the status quo is that the > current RM wording tends to encourage the common misconception that > arguments to pragmas can be reordered (further fueled by the fact that > all DEC extra > pragmas allow such reordering). Well, I've always thought that reordering should be allowed (if the arguments have names, most don't). I don't much want to have to implement that, but it is just too inconsistent with the rest of the language to not allow it. But this whole issue was discussed in the context of AI-00036, so I have to wonder if enough has changed in the intervening years to reopen the discussion. But if we want to do something in *this* Amendment, we need an AI in the next few hours, as the final agenda for Boston will be frozen tomorrow morning -- and we won't consider anything non-essential after we leave Boston. (We're still planning to start the formal approval process this summer.) **************************************************************** From: Pascal Leroy Date: Tuesday, April 12, 2005 12:09 PM > I don't see the purpose of this arbitrary rule, which serves > no functional goal. It seems to go half way but no further in > drawing tha analogy between pragmas and subprogram calls. You might want to take a look at AI95-00036 where this and other rules were discussed, and it was decided to preserve the status quo. > I think we should either remove this useless rule, or go all > the way and say that if argument identifiers are given, then > arguments can be reordered. If we discuss this topic, I am going to vehemently argue against the "no reordering" rule which is actively harmful, doesn't simplify implementations, and can only degrade readability. You must be aware though that there is an ARG meeting next week-end, so if you want this topic to be discussed at that meeting, you'll need to send an AI within the next 24 hours. **************************************************************** From: Robert Dewar Date: Tuesday, April 12, 2005 7:53 AM > I think the reason we didn't allow reordering is that it's easier > to write the RM that way. The rules are presented in BNF, and it would > either increase the size of the BNF, or require a special rule that > says, "never mind what the BNF says; you can reorder". > In fact, now that I think about it, doesn't RM 2.8(4) *follow* > from the BNF rules? chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No, this section does not follow from the BNF rules. They could have been written that way but it would [greatly] "increase the size of the BNF", so instead we introduced the special rule 2.8(4) that says "never mind what the BNF says; you can't mix named/positional". Ugly! Or if you tolerate this ugliness, then why not go a step forward and allow ordering. The current rule is completely useless and serves no functin, at least a rule allowing ordering would serve some purpose. > > I wouldn't mind allowing mixed named/positional, if this were 1992, > but at this point, I think: not sufficiently broken to bother fixing. Well it's a minor cleanup. This check won't fall out free for any compiler, since it is a perturbation to the syntax, it will have to be checked by a junk specific check, easxy to remove, so certainly no burden on compilers to remove this rule. As for the quoted AI, it really doesn't address this issue, but instead the issue of clearly wrong BNF syntax for pragma Import, I trust this will be fixed! **************************************************************** From: Bob Duff Date: Friday, April 15, 2005 8:08 AM > chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No, > this section does not follow from the BNF rules. I don't understand why. For example, 11.5 says: Syntax 3 The form of a pragma Suppress is as follows: 4 pragma Suppress(identifier [, [On =>] name]); which does *not* allow: pragma Suppress(On => Mumble, Range_Check); And all the other pragmas have similar syntax. It seems to me that if we wanted to allow that, we would need more complicated BNF for many of the pragmas, or else we would need a kludgy rule overriding the BNF. (Well, it's not really BNF -- it's a sort of pseudo-BNF.) And we would be in danger of allowing: pragma Suppress(Mumble, Range_Check); which seems like trouble. Or: type Range_Check is range 1..10; pragma Suppress(Range_Check, Range_Check); **************************************************************** From: Robert Dewar Date: Friday, April 15, 2005 9:04 AM >>chuckle chuckle, this is EXACTLY why I don't like 2.8(4). No, >>this section does not follow from the BNF rules. > I don't understand why. For example, 11.5 says: An example cannot disprove what I say, but an example can confirm it: 7 pragma Convention([Convention =>] convention_identifier,[Entity =>] local\ _name); 14 pragma Import( [Convention =>] convention_identifier, [Entity =>] local_ name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); -- See B.1. 13 pragma Export( [Convention =>] convention_identifier, [Entity =>] local_ name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); -- See B.1. Interestingly, these are the only three cases in the RM where the issue arises (though in a real compiler, there are of course dozens of other examples :-) So indeed 2.8(4) is a real additional constraint. It is quite a nuisance to try to get this rule into the BNF for a pragma. > And all the other pragmas have similar syntax. clearly a false claim :-) > which does *not* allow: > > pragma Suppress(On => Mumble, Range_Check); > > And all the other pragmas have similar syntax. It seems to me that if > we wanted to allow that, we would need more complicated BNF for many of > the pragmas, or else we would need a kludgy rule overriding the BNF. > (Well, it's not really BNF -- it's a sort of pseudo-BNF.) 2.8(4) has nothing to do with reordering, but certainly we would not want to allow the above Suppress example, reordering only makes sense for named parameters, as in the case of subprograms. But it would make perfect sense to allow: pragma Convention (Entity => Myfunc, Convention => C); > And we would be in danger of allowing: > > pragma Suppress(Mumble, Range_Check); > > which seems like trouble. Or: > > type Range_Check is range 1..10; > pragma Suppress(Range_Check, Range_Check); Gosh this is a *bright red* herring. Obviously reordering would only be allowed in the case of named parameters, as for subprograms. A prototype rule would be 2.8(?) Pragma arguments for which pragma identifiers are given may appear in any order. I think that would be 100% clear (you still keep 2.8(4), thus forbidding obviously wrong examples such as Bob quotes above). My choice would still be simply to eliminate 2.8(4). The fact that Bob Duff did not even realize that this rule had an impact is indicative of its obscurity, and a good argument for eliminating it. **************************************************************** From: Bob Duff Date: Friday, April 15, 2005 9:47 AM ... > 14 pragma Import( [Convention =>] convention_identifier, [Entity =>] local_ > name [, [External_Name =>] string_expression] [, [Link_Name =>] > string_expression]); -- See B.1. > > 13 pragma Export( [Convention =>] convention_identifier, [Entity =>] local_ > name [, [External_Name =>] string_expression] [, [Link_Name =>] > string_expression]); -- See B.1. OK, now I get it. I didn't realize those pragmas were written that way. > Interestingly, these are the only three cases in the RM where the issue > arises (though in a real compiler, there are > of course dozens of other examples :-) Well, the syntax of the implementation-defined ones is of course implementation defined, so you can do what you like. I admit that it's annoying to have two different paths in the compiler, one for the language-defined pragmas, and one for the others. > So indeed 2.8(4) is a real additional constraint. It is quite a nuisance > to try to get this rule into the BNF for a pragma. > > > And all the other pragmas have similar syntax. > > clearly a false claim :-) Apparently. ;-) ... > A prototype rule would be > > 2.8(?) Pragma arguments for which pragma identifiers are given may appear > in any order. > > I think that would be 100% clear (you still keep 2.8(4), thus forbidding > obviously wrong examples such as Bob quotes above). Yes, that seems like fine wording. I still don't think it's worth the trouble to fix, but I don't have any strong objection. ****************************************************************