!standard 13.12.1(1/2) 11-04-18 AI05-0241-1/04 !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). Some people are uncomfortable with the rather leaky-colander-like semantics of Dynamic_Predicate in particular, 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. ****************************************************************