!standard 13.12.1(1/2) 11-03-11 AI05-0241-1/03 !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_Aspects follows directly from the existence of No_Implementation_Attributes and No_Implementation_Pragmas. The need for No_Aspect_Specification 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_Aspects forbids specification of relevant aspects via any means. For those aspects that correspond to attributes, it also forbids queries. In contrast, No_Aspect_Specification does not forbid queries. Note that No_Aspect_Specification can be used for both language-defined and implementation-defined aspects. !example pragma Restrictions(No_Implementation_Aspects); pragma Restrictions(No_Aspect_Specification => 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. ;-) ****************************************************************