Version 1.7 of ai05s/ai05-0241-1.txt
!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 => <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_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)
Insert after the paragraph:
The following restriction_identifiers are language-defined (additional
restrictions are defined in the Specialized Needs Annexes):
the new paragraph:
- 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.
!corrigendum 13.12.1(5/2)
Replace the paragraph:
The following restriction_parameter_identifier is language defined:
by:
The following restriction_parameter_identifiers are language defined:
!corrigendum 13.12.1(6/2)
Insert after the paragraph:
- No_Dependence
-
Specifies a library unit on which there are no semantic dependences.
the new paragraph:
- No_Specification_of_Aspect
-
Identifies an aspect for which no aspect_specification,
attribute_definition_clause, or pragma is given.
!corrigendum 13.12.1(7/2)
Insert after the paragraph:
The restriction_parameter_argument of a No_Dependence restriction shall be
a name; the name shall have the form of a full expanded name of a
library unit, but need not denote a unit present in the environment.
the new paragraph:
The restriction_parameter_argument of a No_Specification_of_Aspect restriction
shall be an identifier; this identifier does not denote any declaration.
!corrigendum 13.12.1(8/2)
Replace the paragraph:
No compilation unit included in the partition shall depend semantically
on the library unit identified by the name.
by:
No compilation unit included in the partition shall depend semantically
on the library unit identified by the name 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
<blah>, that also should preclude using a language-defined <blah> 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.
****************************************************************
Questions? Ask the ACAA Technical Agent