Version 1.2 of ai05s/ai05-0241-1.txt
!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 Easy
!subject Aspect-related restrictions
!summary
Two aspect-related restrictions are defined:
pragma Restrictions(No_Implementation_Aspects);
pragma Restrictions(No_Aspect_Specification => <aspect-identifier>);
!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_Aspects
There are no implementation-defined aspects, attributes, pragmas,
or pragma arguments. 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(5/2):
No_Aspect_Specification
Identifies an aspect for which no aspect specification,
attribute_definition_clause, or pragma is given.
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.
!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);
!ACATS test
Add ACATS B tests for this feature.
!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.
;-)
****************************************************************
Questions? Ask the ACAA Technical Agent