CVS difference for ai05s/ai05-0241-1.txt
--- ai05s/ai05-0241-1.txt 2012/01/05 06:19:33 1.8
+++ ai05s/ai05-0241-1.txt 2012/04/21 02:33:12 1.9
@@ -1,4 +1,4 @@
-!standard 13.12.1(1/2) 11-04-18 AI05-0241-1/04
+!standard 13.12.1(1/2) 12-04-20 AI05-0241-1/05
!standard 13.12.1(5/2)
!standard 13.12.1(6/2)
!standard 13.12.1(7/2)
@@ -80,18 +80,19 @@
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.
+predicates (see AI05-0153-3). In particular, some people are uncomfortable with
+the rather leaky-colander-like semantics of Dynamic_Predicate (which can change
+to False for initialized, previously checked objects), 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,
+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
@@ -616,3 +617,441 @@
been annoying.
****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 26, 2011 4:27 PM
+
+> Some people are uncomfortable with the rather leaky-colander-like
+> semantics of Dynamic_Predicate in particular
+
+I object the the "rather leaky-colander-like" here. First I think it's plain
+wrong, second, this kind of editorializing has no place in the discussion
+section.
+
+Good enough to say "with the semantics of ...."
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, August 26, 2011 5:04 PM
+
+...
+> I object the the "rather leaky-colander-like" here. First I think it's
+> plain wrong, second, this kind of editorializing has no place in the
+> discussion section.
+
+I beg to differ.
+
+It's not "plain wrong": the semantics of Dynamic_Predicate really *are* leaky
+and colander-like. There are all sorts of cases where the Dynamic_Predicate,
+which you would like to be true "always", is false. You and I think that's just
+fine ("so don't do that"); others are uncomfortable with it, and the discussion
+adequately explains.
+
+And where else would one put editorializing? It belongs in the !discussion
+section, not in the RM.
+
+I think maybe I wrote this AI (I don't remember -- maybe it was Randy or someone
+else). The "colander" metaphor is from John Barnes.
+
+Of course, "leaky-colander-like" is a redundancy.
+Imagine this advertisement: "Buy AdaCore's colanders, which don't leak! Not
+available in stores!" ;-)
+
+> Good enough to say "with the semantics of ...."
+
+I don't strongly object, but it seems watered down (doesn't explain why they are
+uncomfortable).
+
+P.S. Probably Randy will point out that this AI is approved, and not subject to
+change without some new information.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 26, 2011 5:10 PM
+
+>> Good enough to say "with the semantics of ...."
+>
+> I don't strongly object, but it seems watered down (doesn't explain
+> why they are uncomfortable).
+
+Well as written it states that the semantics *ARE* LACL. If you want to keep
+this phrase make it clear that this is the opinion of some, rather than a
+statement of fact.
+
+Perhaps
+
+ >>> Some people feel that the semantics of Dynamic_Predicate
+ >>> are "leaky-colandar-like" and hence would like a way of
+ >>> forbidding the use of this feature.
+
+the reason I think it is nonsense is that all subtype declarations are like
+this, if you say
+
+ subtype X is Integer range 1 .. 10;
+
+it does not mean that all objects of type X are in this range!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, August 26, 2011 5:34 PM
+
+> Well as written it states that the semantics *ARE* LACL.
+
+LCL?
+
+>...If you want to keep this phrase make it clear that this is the
+>opinion of some, rather than a statement of fact.
+
+I think it's a correct statement of fact. The semantics allow those predicates
+to be false (in poorly-written programs), sometimes.
+
+> Perhaps
+>
+> >>> Some people feel that the semantics of Dynamic_Predicate >>> are
+> "leaky-colandar-like" and hence would like a way of >>> forbidding
+> the use of this feature.
+
+I prefer to say that the semantics ARE colandar-like, and some (not you and me)
+find that uncomfortable.
+
+> the reason I think it is nonsense is that all subtype declarations are
+> like this, if you say
+>
+> subtype X is Integer range 1 .. 10;
+>
+> it does not mean that all objects of type X are in this range!
+
+Yeah, the semantics of range constraints are also leaky, and colander-like,
+which is a point I made in AI-153-3. My point was not "no colanders here", but
+"colander-like semantics is no huge problem, because we've got that already".
+
+To me, it just seems more honest to admit that there's a problem that we can't
+solve, than to deny the existence of the problem.
+
+Besides, I like colorful prose -- it gets boring reading this stuff, without
+John's colorful "colander" analogy.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 26, 2011 5:48 PM
+
+>> Well as written it states that the semantics *ARE* LACL.
+>
+> LCL?
+
+Right, I copied your Leaky And Colander-Like :-)
+
+>> ...If you want to keep this phrase make it clear that this is the
+>> opinion of some, rather than a statement of fact.
+>
+> I think it's a correct statement of fact. The semantics allow those
+> predicates to be false (in poorly-written programs), sometimes.
+
+Well I disagree, it is a judgment, just because they can be false, is no reason
+to describe them in such perjorative terms. As I say, I don't mind you having
+the *opinion* that they are LCL, but I object to stating this as a matter of
+fact.
+
+> I prefer to say that the semantics ARE colandar-like, and some (not
+> you and me) find that uncomfortable.
+
+I still don't like applying the pejorative description as fact. If you want to
+find some more neutral technical description, fine.
+
+> Yeah, the semantics of range constraints are also leaky, and
+> colander-like, which is a point I made in AI-153-3.
+> My point was not "no colanders here", but "colander-like semantics is
+> no huge problem, because we've got that already".
+>
+> To me, it just seems more honest to admit that there's a problem that
+> we can't solve, than to deny the existence of the problem.
+
+I don't think it is a problem
+
+> Besides, I like colorful prose -- it gets boring reading this stuff,
+> without John's colorful "colander" analogy.
+
+I still don't like the pejorative tone! Find something less colorful if you
+insist on presenting it as fact.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, August 26, 2011 6:27 PM
+
+> Right, I copied your Leaky And Colander-Like :-)
+
+;-)
+
+> Well I disagree, it is a judgment, just because they can be false, is
+> no reason to describe them in such perjorative terms.
+
+OK, I agree that "leaky" and "colander-like" are perjorative terms (and
+"leaky-colander-like" is both perjorative and redundant). The fact is, they can
+be false when you might wish they were true.
+
+How about:
+
+ Some people are uncomfortable with the fact that the semantics of
+ Dynamic_Predicate allow those predicates to be False at some points
+ in the program, and hence would like a way of forbidding the use of
+ this feature.
+
+?
+
+Or add "(for rather poorly-written programs)" after "fact that"
+to bias it the other way?
+
+> > To me, it just seems more honest to admit that there's a problem
+> > that we can't solve, than to deny the existence of the problem.
+>
+> I don't think it is a problem
+
+I know, but some folks do, and I understand their point of view, even though I
+disagree with it. I mean, if Ada were a functional language, or had
+globals-annotations like SPARK, then we really *could* solve this "problem".
+And the whole point of this AI is to compromise with folks who find this "issue"
+to be a "problem"; we need to acknowledge that.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 26, 2011 9:20 PM
+
+> How about:
+>
+> Some people are uncomfortable with the fact that the semantics of
+> Dynamic_Predicate allow those predicates to be False at some points
+> in the program, and hence would like a way of forbidding the use of
+> this feature.
+
+I think that's fine
+>
+> ?
+>
+> Or add "(for rather poorly-written programs)" after "fact that"
+> to bias it the other way?
+
+Not needed I would say
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, August 27, 2011 11:48 PM
+
+I find this whole discussion rather pointless. The discussion section of an AI
+is about the eighth priority at this point -- only the contents of the AARM will
+matter to 95% of the readers. I felt strongly enough to send this comment from
+Lizard Creek, Grand Teton National Park (which has decent cell reception).
+Please spend your time reviewing the AARM - September 12 is fast approaching.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 28, 2011 6:56 AM
+
+Actually to me, I never read the AARM when implementing Ada 2012 features, I
+*only* read the relevant AI's. Of course the AARM should be as accurate as
+possible, but ultimately we spend a lot of time worrying about wording in the
+AARM which probably doesn't matter very much. For example, the whole discussion
+of what satisfying a predicate means seemed totally pointless to me. So I guess
+different people have different concerns, which is why it is good to have a
+bunch of different people reading things.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, September 5, 2011 2:10 AM
+
+> And where else would one put editorializing? It belongs in the
+> !discussion section, not in the RM.
+>
+> I think maybe I wrote this AI (I don't remember -- maybe it was Randy
+> or someone else). The "colander" metaphor is from John Barnes.
+>
+
+And John feels that this stuff should be removed from Ada 2012 completely.
+You can put it in a later version when it's been thought about a bit more.
+And maybe I will be dead or at least totally past it and won't care.
+
+Tchah
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, September 7, 2011 7:15 AM
+
+Can't we just call this No_Implementation_Aspects?
+Fits much better with the other set of names, and I see no reason for the junk
+long name, it adds nothing but language lawyer inconvenience.
+
+After all, it is No_Implementation_Units, not
+No_Implementation_Compilation_Units.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, September 7, 2011 8:27 AM
+
+I suggested that some months ago when making a list of the wretched things
+in the Rat but I was shouted down. It would be an excellent change. We can
+class it as a typo.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, September 7, 2011 8:36 AM
+
+I just implemented this restriction (was not entirely trivial to do) and before
+I check it in, and set it in stone, I wanted to make the appeal to give it a
+reasonable name.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, September 7, 2011 8:56 AM
+
+The distinction is relevant because
+this restriction says nothing about the implementation adding their own pragmas
+or attributes, even though they might be considered to be defining aspects.
+
+This restriction is specifically about aspect *specifications*, not more
+generally about aspects.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, September 7, 2011 9:30 AM
+
+> Can't we just call this No_Implementation_Aspects?
+
+This was discussed. I don't remember which side I was on, but the idea is that
+it forbids setting the aspect, but not querying them, via attributes. Use
+No_Impl_Attr for that.
+
+> Fits much better with the other set of names, and I see no reason for
+> the junk long name, it adds nothing but language lawyer inconvenience.
+
+Well, the shorter name could be confusing, which is not a language-lawyer
+reason.
+
+You use this thing approximately once per program, so shortening it saves
+little.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, September 7, 2011 9:44 AM
+
+Robert There you are. I knew they would be grumpy!!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, September 7, 2011 8:50 AM
+
+> The distinction is relevant because
+> this restriction says nothing about the implementation adding their
+> own pragmas or attributes, even though they might be considered to be
+> defining aspects.
+>
+> This restriction is specifically about aspect *specifications*, not
+> more generally about aspects.
+
+Harrumph! this strikes me as language lawyers striking again, yes, I know that
+the language lawyers think that pragma Pack specifies an aspect, but no
+programmer will know that.
+
+Actually I cannot see that forbidding an aspect specification from specifying
+Special_Pack, without also forbidding pragma Special_Pack makes ANY sense.
+
+Can anyone give a convincing example where you want to forbid the use of an
+aspect, but not forbid the use of an equivalent pragma or attribute definition
+clause.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, September 7, 2011 8:51 AM
+
+> You use this thing approximately once per program, so shortening it
+> saves little.
+
+OK, no big deal I suppose, I will live with the junk name. Actually I think I
+will also implement
+
+No_Implementation_Aspects, which will do what you would expect from a language
+lawyer point of view, stop all aspects however accessed.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, September 7, 2011 11:54 PM
+
+> Can anyone give a convincing example where you want to forbid the use
+> of an aspect, but not forbid the use of an equivalent pragma or
+> attribute definition clause.
+
+Downward compatibility?
+OK, better use -gnat2005
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 8, 2011 10:10 AM
+
+Note to Randy: 13.12.1(1.1/3) has the wrong AI number:
+
+1.1/3 {AI05-0242-1} 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.
+
+Should be AI05-0241-1.
+ ^
+
+> Can anyone give a convincing example where you want to forbid the use
+> of an aspect, but not forbid the use of an equivalent pragma or
+> attribute definition clause.
+
+No, I can't. But this was discussed, and it was decided that
+No_Implementation_Aspect_Specifications doesn't apply to pragmas or
+attribute_definition_clauses. If you look at the AI, you'll see Robert Dewar
+agreeing with this decision! ;-) On this point, I say "too late to change".
+
+But that's not the point. The reason it should be
+No_Implementation_Aspect_Specifications rather than No_Implementation_Aspects is
+for attributes -- queries. For example, No_Implementation_Aspect_Specifications
+forbids:
+
+ for T'Object_Size use ...;
+
+but does NOT forbid:
+
+ X : Integer := T'Object_Size;
+
+And I think that's what we want. We have a different restriction for forbidding
+queries.
+
+No_Implementation_Aspects would imply that it DOES forbid the query, which would
+be misleading. Neither you nor John have addressed that point, IIRC, other than
+to accuse me of being grumpy or overly language-lawyerly. I don't think being
+concerned over a misleading name is language-lawyerly -- it's a very
+user-oriented/practical concern.
+
+And it's certainly not important enough to be grumpy about! ;-)
+
+****************************************************************
+
+From: John Barnes
+Sent: Friday, September 9, 2011 11:43 AM
+
+John is reasonably happy. Remember that I favour Truth before Beauty ( as in
+Salem). And I am not grumpy today. But tomorrow could be another story.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent