CVS difference for ai05s/ai05-0241-1.txt
--- ai05s/ai05-0241-1.txt 2011/02/10 05:57:42 1.1
+++ ai05s/ai05-0241-1.txt 2011/02/11 06:39:33 1.2
@@ -1,9 +1,10 @@
-!standard 13.12.1(0) 11-02-09 AI05-0241-1/01
+!standard 13.12.1(1/2) 11-02-11 AI05-0241-1/02
+!standard 13.12.1(5/2)
!class Amendment 11-02-09
!status work item 11-02-09
!status received 11-01-24
!priority Low
-!difficulty Low
+!difficulty Easy
!subject Aspect-related restrictions
!summary
@@ -22,7 +23,7 @@
!proposal
-See wording.
+(See wording.)
!wording
@@ -51,9 +52,8 @@
Add after 13.12.1(5/2):
No_Aspect_Specification
- Specifies an aspect that is not specified, either by an
- aspect_specification, an attribute_definition_clause, or a
- pragma.
+ Identifies an aspect for which no aspect specification,
+ attribute_definition_clause, or pragma is given.
Legality Rules
@@ -98,57 +98,10 @@
!ACATS test
-Add ACATS B and C tests for this feature.
+Add ACATS B tests for this feature.
!appendix
-From: Robert Dewar
-Sent: Monday, July 26, 2010 7:46 PM
-
-Implementations are allowed to add grandchildren to Ada etc. And GNAT
-takes advantage of this, e.g. to add the encoding packages to earlier
-versions of Ada.
-
-But this creates portability problems, we should really have a
-restriction to prevent this, in the style of No_Implementation_Pragmas.
-
-How about No_Implementation_Units
-
-?
-
-I am not really suggesting a new AI at this stage, just some guidance
-on whether this is a good idea so that implementations can adopt it
-(and then we can put it into Ada 2019 :-))
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Monday, July 26, 2010 8:14 PM
-
-This sounds like a very good idea.
-Users are often confused about what
-packages are "standard" Ada and what
-are not.
-
-Does this also cover System.* and Interfaces.*?
-One rule might be to disallow any package that starts with "Ada", "System",
-or "Interfaces" that is not in the reference manual. These are the ones
-that confuse users.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, July 26, 2010 8:33 PM
-
-Right, that's what I had in mind.
-
-And the idea would be in particular to forbid use of RM packages in an
-inappropriately earlier version of Ada (e.g. using the string encoding packages
-in Ada 2005 mode). Of course I know that can't be part of the standard, but
-that would be the encouraged usage (and is what GNAT intends to do).
-
-****************************************************************
-
From: Bob Duff
Sent: Monday, January 24, 2011 9:52 AM
@@ -231,3 +184,165 @@
****************************************************************
+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.
+;-)
+
+****************************************************************
Questions? Ask the ACAA Technical Agent