!standard 13.12.1(1/2) 12-04-20 AI05-0241-1/05 !standard 13.12.1(5/2) !standard 13.12.1(6/2) !standard 13.12.1(7/2) !standard 13.12.1(8/2) !class Amendment 11-02-09 !status Amendment 2012 11-03-11 !status ARG Approved 7-0-1 11-02-19 !status work item 11-02-09 !status received 11-01-24 !priority Low !difficulty Easy !subject Aspect-related restrictions !summary Two aspect-related restrictions are defined: pragma Restrictions(No_Implementation_Aspect_Specifications); pragma Restrictions(No_Specification_of_Aspect => ); !problem Given the new aspect_specification syntax, it is important to provide a way to forbid implementation-defined ones, analogous to No_Implementation_Attributes and No_Implementation_Pragmas. Also, it is important to provide a way to forbid the specification of particular aspects, analogous to No_Dependence. !proposal (See wording.) !wording Add after 13.12.1(1/2): No_Implementation_Aspect_Specifications There are no implementation-defined aspects specified by an aspect_specification. This restriction applies only to the current compilation or environment, not the entire partition. AARM note: Discussion: This restriction (as well as others below) applies only to the current compilation, because it is likely that the runtime (and possibly user-written low-level code) will need to use implementation-defined aspects. But a partition-wide restriction applies everywhere, including the runtime. Delete 13.12.1(2.a/2), which is subsumed by the above AARM "Discussion". Modify 13.12.1(5/2): The following restriction_parameter_identifier{s are} [is] language defined: Add after 13.12.1(6/2): No_Specification_of_Aspect Identifies an aspect for which no aspect_specification, attribute_definition_clause, or pragma is given. Add after 13.12.1(7/2): The restriction_parameter_argument of a No_Specification_of_Aspect restriction shall be an identifier; this identifier does not denote any declaration. AARM note: Ramification: This restriction_parameter_argument is not resolved. As for No_Dependence, there is no check that the aspect identifier is meaningful; it might refer to an implementation-defined aspect on one implementation, but nothing at all on another implementation. Of course, a good implementation will warn if the aspect is unknown to it. !discussion The need for No_Implementation_Aspect_Specifications follows directly from the existence of No_Implementation_Attributes and No_Implementation_Pragmas. The need for No_Specification_of_Aspect came up during the discussion of subtype predicates (see AI05-0153-3). In particular, some people are uncomfortable with the rather leaky-colander-like semantics of Dynamic_Predicate (which can change to False for initialized, previously checked objects), so there should be a way to self-impose a restriction forbidding the specification of this aspect on some projects. Rather than invent a particular restriction for that purpose, it seems obviously cleaner to have a general-purpose restriction that can be used with any aspect. The history leading to No_Dependence affirms the wisdom of this choice. Note that No_Implementation_Aspect_Specifications only forbids specification of relevant aspects via aspect_specifications. For those aspects that correspond to attributes, they may be queried or specified by attribute_definition_clauses. (These can be forbidden by No_Implementation_Attributes.) Similarly, No_Specification_of_Aspect does not forbid queries. Note that No_Specification_of_Aspect can be used for both language-defined and implementation-defined aspects. !example pragma Restrictions(No_Implementation_Aspect_Specifications); pragma Restrictions(No_Specification_of_Aspect => Dynamic_Predicate); !corrigendum 13.12.1(1/2) @dinsa The following @i@fas are language-defined (additional restrictions are defined in the Specialized Needs Annexes): @dinst @xhang<@xterm There are no implementation-defined aspects specified by an @fa. This restriction applies only to the current compilation or environment, not the entire partition.> !corrigendum 13.12.1(5/2) @drepl The following @i@fa is language defined: @dby The following @i@fas are language defined: !corrigendum 13.12.1(6/2) @dinsa @xhang<@xterm Specifies a library unit on which there are no semantic dependences.> @dinst @xhang<@xterm Identifies an aspect for which no @fa, @fa, or @fa is given.> !corrigendum 13.12.1(7/2) @dinsa The @fa of a No_Dependence restriction shall be a @fa; the @fa shall have the form of a full expanded name of a library unit, but need not denote a unit present in the environment. @dinst The @fa of a No_Specification_of_Aspect restriction shall be an @fa; this @fa does not denote any declaration. !corrigendum 13.12.1(8/2) @drepl No compilation unit included in the partition shall depend semantically on the library unit identified by the @fa. @dby No compilation unit included in the partition shall depend semantically on the library unit identified by the @fa of a No_Dependence restriction. !ACATS test Add ACATS B tests for this feature. !ASIS No ASIS effect (Restrictions are not handled specially by ASIS). !appendix From: Bob Duff Sent: Monday, January 24, 2011 9:52 AM > P.S. should we have a restriction > > No_Implementation_Aspects Yes, good idea. **************************************************************** From: Bob Duff Sent: Monday, January 24, 2011 10:02 AM By the way, obviously some folks would like to forbid Dynamic_Predicate, so there should be a restriction for that. Instead of doing it piecemeal, we should do like we did for No_Dependence, and have a general feature for forbidding any aspect. Something like: pragma Restrictions (No_Aspect => Dynamic_Predicate); We could have an enum type somewhere that lists all the aspect names. Or we could just allow an "aspect_identifier" there, without involving visibility -- like pragma arguments. For aspects that are also attributes or pragmas, the restriction should forbid both forms. I've got no problem with self-imposed or project-imposed restrictions! If, someday, some customer requests No_Evil_Predicates, I expect AdaCore would implement it (if we can come up with a coherent definition of "evil"). **************************************************************** From: Tucker Taft Sent: Monday, January 24, 2011 10:19 AM Or perhaps something like: pragma Restrictions(No_Aspect_Specification => Dynamic_Predicate); to be analogous to "No_Dependence => ...". **************************************************************** From: Bob Duff Sent: Monday, January 24, 2011 10:38 AM Yes, that's better. For those aspects that are also attributes, you probably want to restrict the specification, but not the query. **************************************************************** From: Robert Dewar Sent: Tuesday, January 25, 2011 6:14 AM > Or perhaps something like: > > pragma Restrictions(No_Aspect_Specification => > Dynamic_Predicate); > > to be analogous to "No_Dependence => ...". Can't we just have No_Aspect => name I see no advantage to reader or writer in adding the Specification part here, especially if it also bans a corresponding pragma or attribute. **************************************************************** From: Robert Dewar Sent: Tuesday, January 25, 2011 6:15 AM > Yes, that's better. For those aspects that are also attributes, you > probably want to restrict the specification, but not the query. > >> to be analogous to "No_Dependence => ...". OK, I see, grumble, I guess the long name will have to do **************************************************************** From: Steve Baird Sent: Thursday, February 10, 2011 12:29 PM ... > Legality Rules > > The restriction_parameter_argument of a No_Aspect_Specification > restriction shall be an identifier; this identifier does not denote any declaration. > > AARM note: > > Ramification: This restriction_parameter_argument is not resolved. > As for No_Dependence, there is no check that the aspect identifier is > meaningful; it might refer to an implementation-defined aspect on one > implementation, but nothing at all on another implementation. Of > course, > a good implementation will warn if the aspect is unknown to it. > > I agree with the intent regarding unrecognized aspect names, but I think we need more than an AARM note to specify this. For the analogous case of No_Dependence, we have "real" wording: 13.12.1(7/2). How about appending something like the following to the proposed Legality rule: The restriction_parameter_argument need not name an aspect. If it does not, the pragma imposes no restriction. and the AARM note could be left unchanged. Also, does anyone else see anything odd about the wording "Specifies an aspect that is not specified" , or am I just being pedantic? **************************************************************** From: Edmond Schonberh Sent: Thursday, February 10, 2011 12:41 PM ... > Also, does anyone else see anything odd about the wording > "Specifies an aspect that is not specified" > , or am I just being pedantic? It is a little clunky. What about: specifies an aspect for which no aspect specification, attribute_definition_clause, or pragma is given. **************************************************************** From: Tucker Taft Sent: Thursday, February 10, 2011 1:40 PM > Also, does anyone else see anything odd about the wording "Specifies > an aspect that is not specified" > , or am I just being pedantic? How about "Identifies an aspect that is not specified, ..." **************************************************************** From: Bob Duff Sent: Thursday, February 10, 2011 1:58 PM > I agree with the intent regarding unrecognized aspect names, but I > think we need more than an AARM note to specify this. I disagree. The wording "does not denote any declaration" seems clear enough. I admit that it's kind of fishy, but to fix it "right", we need to change the syntax of restriction_parameter_argument, and I was told (in the Jan. phone meeting) not to bother with that. Anyway, if it were required to be an aspect name, we would need a legality rule saying so. > For the analogous case of No_Dependence, we have "real" wording: > 13.12.1(7/2). The wording for No_Dependence is completely screwed up, IMHO, so I felt no obligation to follow that. The intent is clear enough, so I don't want to fix No_Dependence. > How about appending something like the following to the proposed > Legality rule: > > The restriction_parameter_argument need not name an > aspect. If it does not, the pragma imposes no restriction. > > and the AARM note could be left unchanged. Grumble -- no strong objection, but I don't think it's necessary. > Also, does anyone else see anything odd about the wording > "Specifies an aspect that is not specified" > , or am I just being pedantic? > " It seemed odd to me when I wrote it! Not wrong, just odd. Ed replied: > It is a little clunky. What about: > > specifies an aspect for which no aspect specification, > attribute_definition_clause, or pragma is given. OK, I like Ed's wording. **************************************************************** From: Bob Duff Sent: Thursday, February 10, 2011 2:00 PM > How about "Identifies an aspect that is not specified, ..." I slightly prefer Ed's wording. But either one is better than what I wrote. Randy, if nobody objects, I suggest you make Ed's change as an editorial change in the CVS version. Or Tuck's change, if that one wins. **************************************************************** From: Randy Brukardt Sent: Friday, February 11, 2011 12:16 AM I prefer a mashup: "Identifies an aspect for which no aspect_specification, attribute_definition_clause, or pragma is given." Specifies is too close to what we do for aspects, so I'd rather not see it at all. This is what I put into the AI (it sometimes comes in handy to be editor :-), pending other comments of course. **************************************************************** From: Randy Brukardt Sent: Friday, February 11, 2011 12:11 AM ... > > For the analogous case of No_Dependence, we have "real" wording: > > 13.12.1(7/2). > > The wording for No_Dependence is completely screwed up, IMHO, so I > felt no obligation to follow that. The intent is clear enough, so I > don't want to fix No_Dependence. "Completely screwed up"?? We spent a lot of time on that, and having re-read it, it seems exactly correct to me. What am I missing? The only guess that I can even hazard is that you don't like the reference to the syntactic "name" in this wording, but that is standard practice for pragmas in the standard, and it doesn't automatically carry any semantic meaning. I would expect to use virtually identical wording for the aspect case. I would agree that I don't want to fix No_Dependence, because it isn't wrong. ;-) **************************************************************** From: John Barnes Sent: Monday, April 18, 2011 8:45 AM While seated one day at my keyboard crafting a bit of rat, I noticed that... This AI is confused over whether the new restriction identifier is No_Implementation_Aspects or No_Implementation_Aspect_Specifications. It is clear from AI-246 that we want No_Implementation_Aspects. **************************************************************** From: Randy Brukardt Sent: Monday, April 18, 2011 10:25 PM Actually, it is clear from the minutes of the February meeting that we wanted No_Implementation_Aspect_Specifications, because this restriction is only talking about the use of an aspect_specification to specify an implementation-defined aspect, as opposed to any use of an implementation-defined aspect (including pragmas and attribute_definition_clauses, which have their own, separate, restrictions). That means that AI05-0246-1 is also (slightly) wrong, but easily fixed. It appears that I updated the !wording, and failed to update the !discussion for both restrictions (both had their name changed). Indeed, there are parts of the discussion that are just wrong. I've rewritten all of that and reposted it. Specifically, the minutes say: AI05-0241-1/02 Aspect-related restrictions Erhard thinks the wording should be "no use of". But this is similar to the first two existing restrictions. Should No_Implementation_Aspects cover pragmas or attributes? No, this just should disallow aspect_specification for implementation-defined aspects. Users have the other restrictions to disallow the other uses. In the second one, put an underscore in aspect_specification. There is confusion between "No_(Aspect_Specification)" and "No_Aspect_(Specification)". Tucker suggests naming these restrictions No_Implementation_Aspect_Specifications and No_Specification_of_Aspect. That seems better. Approve AI with changes: 7-0-1. **************************************************************** From: John Barnes Sent: Tuesday, April 19, 2011 5:16 AM > Actually, it is clear from the minutes of the February meeting that we > wanted No_Implementation_Aspect_Specifications, because this > restriction is only talking about the use of an aspect_specification > to specify an implementation-defined aspect, as opposed to any use of > an implementation-defined aspect (including pragmas and > attribute_definition_clauses, which have their own, separate, > restrictions). > That means that AI05-0246-1 is also (slightly) wrong, but easily fixed. I see the logic. Aspects can be set by pragmas. Truth before beauty. But is that the way users will see it? And it makes the rat ugly. **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 7:36 AM I agree with John, horrible name, I think I will implement both in GNAT, since the shorter name seems so much more convenient and reasonable. It is a language laywer thing to worry about this (sort of like sticking to the notion that its a package declaration rather than a spec, or that generic packages are not packages, or that type declarations introduce subtypes :-)) No_Implementation_Aspects is much clearer and there is no chance of confusion IMO. **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 7:51 AM Somehow, to have an implementation-defined restriction for controlling use of implementation-defined aspect specifications seems a bit counter-productive. ;-) **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 7:53 AM Hmmm, grumble grumble, I suppose you are right. I just hate this hypercorrectism with terminology, NO user will think if aspects in the way the manual thinks of them. **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 7:55 AM > Somehow, to have an implementation-defined restriction for controlling > use of implementation-defined aspect specifications seems a bit > counter-productive. ;-) Hey, how about a profile that is all of these no-implementation-nonsense restrictions combined together, at this stage we have a few, and it would make sense to have a profile Profile (No_Implementation_Extensions); that includes all of them trivial to implement, and I suspect that's what most people will want rather than a delicately chosen subset. **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 8:22 AM Actually, you made this suggestion before, we liked the idea, and it is already part of AI-241. So you were way ahead of yourself... ;-) **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 8:26 AM chuckle chuckle, in practice I suspect that most people will use this profile rather than the individual ones. I havent read through 241 yet, was waiting for it to settle down :-) **************************************************************** From: Randy Brukardt Sent: Tuesday, April 19, 2011 3:38 PM Actually, the profile is in AI05-0246-1. But we definitely intend to include it in Ada 2012. **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 9:14 AM Have we worried about implementation defined check names, and implementation defined policy names? **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 9:30 AM No, though one way to do that might be to include them with implementation-defined pragmas. **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 9:35 AM I think we should, obviously it's in the spirit of saying I only want officially defined pragmas. That should also kill special policies for dispatching etc. **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 9:43 AM Or more generally, if you apply a restriction disallowing implementation-defined , that also should preclude using a language-defined with an implementation-defined identifier or syntax of some sort. **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 9:48 AM Right, I think the proper definition is something like pragma Restriction (No_Implementation_Pragmas); If this restriction is in force, then the only allowed pragmas are those defined in the RM, and the only allowed syntax for these pragmas is that given in the RM. **************************************************************** From: Randy Brukardt Sent: Thursday, April 21, 2011 9:51 PM Actually, you guys need to read the Ada 2005 RM (13.12.1(3/2)): No_Implementation_Pragmas There are no implementation-defined pragmas or pragma arguments. This restriction applies only to the current compilation or environment, not the entire partition. Apparently, this is such a good idea that we had it 10 years ago. :-) This has always been the wording of this restriction, dating back to when the wording was created in June 2001. (On-line version control allows one to find out useless facts. :-) It is good that this already has this definition, because otherwise the rule you were talking about would have been incompatible with Ada 2005, which would be been annoying. **************************************************************** From: Robert Dewar Sent: Friday, August 26, 2011 4:27 PM > Some people are uncomfortable with the rather leaky-colander-like > semantics of Dynamic_Predicate in particular I object the the "rather leaky-colander-like" here. First I think it's plain wrong, second, this kind of editorializing has no place in the discussion section. Good enough to say "with the semantics of ...." **************************************************************** From: Bob Duff Sent: Friday, August 26, 2011 5:04 PM ... > I object the the "rather leaky-colander-like" here. First I think it's > plain wrong, second, this kind of editorializing has no place in the > discussion section. I beg to differ. It's not "plain wrong": the semantics of Dynamic_Predicate really *are* leaky and colander-like. There are all sorts of cases where the Dynamic_Predicate, which you would like to be true "always", is false. You and I think that's just fine ("so don't do that"); others are uncomfortable with it, and the discussion adequately explains. And where else would one put editorializing? It belongs in the !discussion section, not in the RM. I think maybe I wrote this AI (I don't remember -- maybe it was Randy or someone else). The "colander" metaphor is from John Barnes. Of course, "leaky-colander-like" is a redundancy. Imagine this advertisement: "Buy AdaCore's colanders, which don't leak! Not available in stores!" ;-) > Good enough to say "with the semantics of ...." I don't strongly object, but it seems watered down (doesn't explain why they are uncomfortable). P.S. Probably Randy will point out that this AI is approved, and not subject to change without some new information. **************************************************************** From: Robert Dewar Sent: Friday, August 26, 2011 5:10 PM >> Good enough to say "with the semantics of ...." > > I don't strongly object, but it seems watered down (doesn't explain > why they are uncomfortable). Well as written it states that the semantics *ARE* LACL. If you want to keep this phrase make it clear that this is the opinion of some, rather than a statement of fact. Perhaps >>> Some people feel that the semantics of Dynamic_Predicate >>> are "leaky-colandar-like" and hence would like a way of >>> forbidding the use of this feature. the reason I think it is nonsense is that all subtype declarations are like this, if you say subtype X is Integer range 1 .. 10; it does not mean that all objects of type X are in this range! **************************************************************** From: Bob Duff Sent: Friday, August 26, 2011 5:34 PM > Well as written it states that the semantics *ARE* LACL. LCL? >...If you want to keep this phrase make it clear that this is the >opinion of some, rather than a statement of fact. I think it's a correct statement of fact. The semantics allow those predicates to be false (in poorly-written programs), sometimes. > Perhaps > > >>> Some people feel that the semantics of Dynamic_Predicate >>> are > "leaky-colandar-like" and hence would like a way of >>> forbidding > the use of this feature. I prefer to say that the semantics ARE colandar-like, and some (not you and me) find that uncomfortable. > the reason I think it is nonsense is that all subtype declarations are > like this, if you say > > subtype X is Integer range 1 .. 10; > > it does not mean that all objects of type X are in this range! Yeah, the semantics of range constraints are also leaky, and colander-like, which is a point I made in AI-153-3. My point was not "no colanders here", but "colander-like semantics is no huge problem, because we've got that already". To me, it just seems more honest to admit that there's a problem that we can't solve, than to deny the existence of the problem. Besides, I like colorful prose -- it gets boring reading this stuff, without John's colorful "colander" analogy. **************************************************************** From: Robert Dewar Sent: Friday, August 26, 2011 5:48 PM >> Well as written it states that the semantics *ARE* LACL. > > LCL? Right, I copied your Leaky And Colander-Like :-) >> ...If you want to keep this phrase make it clear that this is the >> opinion of some, rather than a statement of fact. > > I think it's a correct statement of fact. The semantics allow those > predicates to be false (in poorly-written programs), sometimes. Well I disagree, it is a judgment, just because they can be false, is no reason to describe them in such perjorative terms. As I say, I don't mind you having the *opinion* that they are LCL, but I object to stating this as a matter of fact. > I prefer to say that the semantics ARE colandar-like, and some (not > you and me) find that uncomfortable. I still don't like applying the pejorative description as fact. If you want to find some more neutral technical description, fine. > Yeah, the semantics of range constraints are also leaky, and > colander-like, which is a point I made in AI-153-3. > My point was not "no colanders here", but "colander-like semantics is > no huge problem, because we've got that already". > > To me, it just seems more honest to admit that there's a problem that > we can't solve, than to deny the existence of the problem. I don't think it is a problem > Besides, I like colorful prose -- it gets boring reading this stuff, > without John's colorful "colander" analogy. I still don't like the pejorative tone! Find something less colorful if you insist on presenting it as fact. **************************************************************** From: Bob Duff Sent: Friday, August 26, 2011 6:27 PM > Right, I copied your Leaky And Colander-Like :-) ;-) > Well I disagree, it is a judgment, just because they can be false, is > no reason to describe them in such perjorative terms. OK, I agree that "leaky" and "colander-like" are perjorative terms (and "leaky-colander-like" is both perjorative and redundant). The fact is, they can be false when you might wish they were true. How about: Some people are uncomfortable with the fact that the semantics of Dynamic_Predicate allow those predicates to be False at some points in the program, and hence would like a way of forbidding the use of this feature. ? Or add "(for rather poorly-written programs)" after "fact that" to bias it the other way? > > To me, it just seems more honest to admit that there's a problem > > that we can't solve, than to deny the existence of the problem. > > I don't think it is a problem I know, but some folks do, and I understand their point of view, even though I disagree with it. I mean, if Ada were a functional language, or had globals-annotations like SPARK, then we really *could* solve this "problem". And the whole point of this AI is to compromise with folks who find this "issue" to be a "problem"; we need to acknowledge that. **************************************************************** From: Robert Dewar Sent: Friday, August 26, 2011 9:20 PM > How about: > > Some people are uncomfortable with the fact that the semantics of > Dynamic_Predicate allow those predicates to be False at some points > in the program, and hence would like a way of forbidding the use of > this feature. I think that's fine > > ? > > Or add "(for rather poorly-written programs)" after "fact that" > to bias it the other way? Not needed I would say **************************************************************** From: Randy Brukardt Sent: Saturday, August 27, 2011 11:48 PM I find this whole discussion rather pointless. The discussion section of an AI is about the eighth priority at this point -- only the contents of the AARM will matter to 95% of the readers. I felt strongly enough to send this comment from Lizard Creek, Grand Teton National Park (which has decent cell reception). Please spend your time reviewing the AARM - September 12 is fast approaching. **************************************************************** From: Robert Dewar Sent: Sunday, August 28, 2011 6:56 AM Actually to me, I never read the AARM when implementing Ada 2012 features, I *only* read the relevant AI's. Of course the AARM should be as accurate as possible, but ultimately we spend a lot of time worrying about wording in the AARM which probably doesn't matter very much. For example, the whole discussion of what satisfying a predicate means seemed totally pointless to me. So I guess different people have different concerns, which is why it is good to have a bunch of different people reading things. **************************************************************** From: John Barnes Sent: Monday, September 5, 2011 2:10 AM > And where else would one put editorializing? It belongs in the > !discussion section, not in the RM. > > I think maybe I wrote this AI (I don't remember -- maybe it was Randy > or someone else). The "colander" metaphor is from John Barnes. > And John feels that this stuff should be removed from Ada 2012 completely. You can put it in a later version when it's been thought about a bit more. And maybe I will be dead or at least totally past it and won't care. Tchah **************************************************************** From: Robert Dewar Sent: Wednesday, September 7, 2011 7:15 AM Can't we just call this No_Implementation_Aspects? Fits much better with the other set of names, and I see no reason for the junk long name, it adds nothing but language lawyer inconvenience. After all, it is No_Implementation_Units, not No_Implementation_Compilation_Units. **************************************************************** From: John Barnes Sent: Wednesday, September 7, 2011 8:27 AM I suggested that some months ago when making a list of the wretched things in the Rat but I was shouted down. It would be an excellent change. We can class it as a typo. **************************************************************** From: Robert Dewar Sent: Wednesday, September 7, 2011 8:36 AM I just implemented this restriction (was not entirely trivial to do) and before I check it in, and set it in stone, I wanted to make the appeal to give it a reasonable name. **************************************************************** From: Tucker Taft Sent: Wednesday, September 7, 2011 8:56 AM The distinction is relevant because this restriction says nothing about the implementation adding their own pragmas or attributes, even though they might be considered to be defining aspects. This restriction is specifically about aspect *specifications*, not more generally about aspects. **************************************************************** From: Bob Duff Sent: Wednesday, September 7, 2011 9:30 AM > Can't we just call this No_Implementation_Aspects? This was discussed. I don't remember which side I was on, but the idea is that it forbids setting the aspect, but not querying them, via attributes. Use No_Impl_Attr for that. > Fits much better with the other set of names, and I see no reason for > the junk long name, it adds nothing but language lawyer inconvenience. Well, the shorter name could be confusing, which is not a language-lawyer reason. You use this thing approximately once per program, so shortening it saves little. **************************************************************** From: John Barnes Sent: Wednesday, September 7, 2011 9:44 AM Robert There you are. I knew they would be grumpy!! **************************************************************** From: Robert Dewar Sent: Wednesday, September 7, 2011 8:50 AM > The distinction is relevant because > this restriction says nothing about the implementation adding their > own pragmas or attributes, even though they might be considered to be > defining aspects. > > This restriction is specifically about aspect *specifications*, not > more generally about aspects. Harrumph! this strikes me as language lawyers striking again, yes, I know that the language lawyers think that pragma Pack specifies an aspect, but no programmer will know that. Actually I cannot see that forbidding an aspect specification from specifying Special_Pack, without also forbidding pragma Special_Pack makes ANY sense. Can anyone give a convincing example where you want to forbid the use of an aspect, but not forbid the use of an equivalent pragma or attribute definition clause. **************************************************************** From: Robert Dewar Sent: Wednesday, September 7, 2011 8:51 AM > You use this thing approximately once per program, so shortening it > saves little. OK, no big deal I suppose, I will live with the junk name. Actually I think I will also implement No_Implementation_Aspects, which will do what you would expect from a language lawyer point of view, stop all aspects however accessed. **************************************************************** From: Jean-Pierre Rosen Sent: Wednesday, September 7, 2011 11:54 PM > Can anyone give a convincing example where you want to forbid the use > of an aspect, but not forbid the use of an equivalent pragma or > attribute definition clause. Downward compatibility? OK, better use -gnat2005 **************************************************************** From: Bob Duff Sent: Thursday, September 8, 2011 10:10 AM Note to Randy: 13.12.1(1.1/3) has the wrong AI number: 1.1/3 {AI05-0242-1} No_Implementation_Aspect_Specifications There are no implementation-defined aspects specified by an aspect_specification. This restriction applies only to the current compilation or environment, not the entire partition. Should be AI05-0241-1. ^ > Can anyone give a convincing example where you want to forbid the use > of an aspect, but not forbid the use of an equivalent pragma or > attribute definition clause. No, I can't. But this was discussed, and it was decided that No_Implementation_Aspect_Specifications doesn't apply to pragmas or attribute_definition_clauses. If you look at the AI, you'll see Robert Dewar agreeing with this decision! ;-) On this point, I say "too late to change". But that's not the point. The reason it should be No_Implementation_Aspect_Specifications rather than No_Implementation_Aspects is for attributes -- queries. For example, No_Implementation_Aspect_Specifications forbids: for T'Object_Size use ...; but does NOT forbid: X : Integer := T'Object_Size; And I think that's what we want. We have a different restriction for forbidding queries. No_Implementation_Aspects would imply that it DOES forbid the query, which would be misleading. Neither you nor John have addressed that point, IIRC, other than to accuse me of being grumpy or overly language-lawyerly. I don't think being concerned over a misleading name is language-lawyerly -- it's a very user-oriented/practical concern. And it's certainly not important enough to be grumpy about! ;-) **************************************************************** From: John Barnes Sent: Friday, September 9, 2011 11:43 AM John is reasonably happy. Remember that I favour Truth before Beauty ( as in Salem). And I am not grumpy today. But tomorrow could be another story. ****************************************************************