CVS difference for ai05s/ai05-0153-3.txt
--- ai05s/ai05-0153-3.txt 2011/02/11 04:57:17 1.8
+++ ai05s/ai05-0153-3.txt 2011/02/11 05:36:45 1.9
@@ -1,4 +1,4 @@
-!standard 3.2.4(0) 11-02-10 AI05-0153-3/04
+!standard 3.2.4(0) 11-02-11 AI05-0153-3/05
!class Amendment 09-05-27
!status work item 09-05-27
!status received 09-05-27
@@ -18,7 +18,7 @@
There are two predicate aspects: Static_Predicate and Dynamic_Predicate.
Static_Predicates must obey certain restrictions, and the subtype can be
-static, so it be used as a choice in case statements and the like.
+static, so it can be used as a choice in case statements and the like.
'for' loops are also defined over subtypes with static predicates.
!problem
@@ -212,6 +212,9 @@
AARM Ramification: Predicates are not evaluated at the point of the [sub]type
declaration.
+AARM Implementation Note: Static_Predicate checks can be removed even in the
+presence of potentially invalid values, just as contraint checks can be removed.
+
If any of the above Legality Rules is violated in an instance of a generic
unit, Program_Error is raised.
In addition to the places where Legality Rules normally apply (see
@@ -222,23 +225,11 @@
wording is included for consistency with similar rules, even though it's
not really necessary, since Program_Error will be raised anyway.
-
- Implementation Permissions
-
-When the Dynamic Semantics calls for a check of a value against a
-Static_Predicate, the check may be omitted if every value that obeys the
-Static_Predicates of the nominal subtype of the value also obeys the
-Static_Predicate being checked against.
-
-AARM Reason: If the implementation does omit a predicate check, it cannot later
-assume that the predicate was True, unless that can be proven.
-
-
NOTE: A predicate clause does not cause a subtype to be considered
"constrained".
-NOTE: Similarly to constraints, a Static_Predicate is always True for all
-objects of the type, except in the case of uninitialized variables and other
+NOTE: Similarly to constraints, a Static_Predicate always remains True for all
+objects of the subtype, except in the case of uninitialized variables and other
invalid values. A Dynamic_Predicate, on the other hand, is checked as specified
above, but can become False at other times. For example, the predicate of a
record is not checked when a subcomponent is modified.
@@ -1697,6 +1688,362 @@
In any case, all of this is not relevant to any current discussion. So let's
drop it here.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011 2:01 PM
+
+[Refering to version /04.]
+
+> There are two predicate aspects: Static_Predicate and Dynamic_Predicate.
+> Static_Predicates must obey certain restrictions, and the subtype can
+> be static, so it be used as a choice in case statements and the like.
+
+ ^^^ "can"
+
+...
+
+> NOTE: Similarly to constraints, a Static_Predicate is always True for
+> all objects of the type, except in the case of uninitialized variables
+> and other invalid values. A Dynamic_Predicate, on the other hand, is
+> checked as specified above, but can become False at other times. For
+> example, the predicate of a record is not checked when a subcomponent is
+> modified.
+
+I find this NOTE pretty confusing. How about:
+
+ NOTE: Similarly to constraints, a Static_Predicate is checked in enough
+ contexts to ensure that it is not violated by any object of the subtype,
+ except in the case of uninitialized variables and other invalid values. A
+ Dynamic_Predicate, on the other hand, is checked only as specified above, but
+ can become False at other times. For example, the Dynamic_Predicate of a
+ record is not checked when a subcomponent is modified.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 10, 2011 2:10 PM
+
+> I find this NOTE pretty confusing.
+
+Please explain why. I find it crystal clear (but I WOULD say that, wouldn't I?
+;-))
+
+> ...How about:
+>
+> NOTE: Similarly to constraints, a Static_Predicate is checked in enough contexts
+> to ensure that it is not violated by any object of the subtype, except in the
+> case of uninitialized variables and other invalid values. A Dynamic_Predicate,
+> on the other hand, is checked only as specified above, but can become
+> False at other times. For example, the Dynamic_Predicate of a
+> record is not checked when a subcomponent is modified.
+
+I find this version confusing, because the issue isn't where they are checked,
+as it seems to imply. The thing that makes Static_Predicates less colander-like
+is the predicate-static restrictions.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011 2:28 PM
+
+>> I find this NOTE pretty confusing.
+>
+> Please explain why. I find it crystal clear (but I WOULD say that,
+> wouldn't I? ;-))
+
+A Static_Predicate is an expression associated with a particular subtype of a
+type, so at a minimum it seems we would want to say:
+
+ ... a Static_Predicate always evaluates to True
+ for every object of the subtype ...
+
+Saying a Static_Predicate is True, to me can easily be interpreted as saying
+that the aspect is specified to be the literal "True." And very importantly,
+this is a subtype predicate, not a type predicate.
+
+>
+>> ...How about:
+>>
+>> NOTE: Similarly to constraints, a Static_Predicate is checked in enough contexts
+>> to ensure that it is not violated by any object of the subtype, except in the
+>> case of uninitialized variables and other invalid values. A Dynamic_Predicate,
+>> on the other hand, is checked only as specified above, but can become
+>> False at other times. For example, the Dynamic_Predicate of a
+>> record is not checked when a subcomponent is modified.
+>
+> I find this version confusing, because the issue isn't where they are
+> checked, as it seems to imply. The thing that makes Static_Predicates
+> less colander-like is the predicate-static restrictions.
+
+It is a combination of the fact that they are checked in all the necessary
+contexts (those that can create or modify the value), and they can't refer to
+other variables and other nasty stuff.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 10, 2011 3:11 PM
+
+> >>> NOTE: Similarly to constraints, a Static_Predicate is always True
+> >>> for all objects of the type, except in the case of uninitialized
+> >>> variables and other
+ SUBtype!
+
+...
+
+> ... a Static_Predicate always evaluates to True
+> for every object of the subtype ...
+>
+> Saying a Static_Predicate is True, to me can easily be interpreted as
+> saying that the aspect is specified to be the literal "True."
+
+I don't think that's a likely misinterpretation. I suppose I could tolerate
+"evaluates to True" instead of "is True", but it seems a little misleading: the
+point is that the predicate remains true even at points in the code where it is
+NOT supposed to be evaluated.
+
+Or how about, "is always True" --> "always remains True"?
+
+What do others think?
+
+> And very importantly, this is a subtype predicate, not a type predicate.
+
+Yes, you're 100% correct about that! I don't know why I wrote "type" when I
+meant "subtype".
+
+...
+> It is a combination of the fact that they are checked in all the
+> necessary contexts (those that can create or modify the value), and
+> they can't refer to other variables and other nasty stuff.
+
+I suppose so, but your version seems to imply that Static_Predicates are checked
+more often than Dynamic_Predicates, which isn't true.
+
+I was told in the phone meeting that the purpose of this NOTE is to sing the
+praises of Static_Predicates, which are gloriously good just like constraints,
+and denigrate the colander-like evils of Dynamic_Predicates. That is, to
+compare/contrast the two.
+
+I think it's better not to explain WHY (too complicated), but just state the
+facts (static ones can be trusted (modulo invalid values), whereas dynamic ones
+can't).
+
+So I propose to fix my "type" --> "subtype", but otherwise leave my wording
+alone.
+
+Opinions?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011 3:28 PM
+
+> Or how about, "is always True" --> "always remains True"?
+>
+> What do others think?
+
+I prefer "always remains True". It avoids saying "is True" which at least to me
+was misleading, since the predicate is an expression, not a simple value. This
+is particularly important because other aspects *are* simple values (like 'Size,
+'Low_Order_First, etc.).
+
+> So I propose to fix my "type" --> "subtype", but otherwise leave my
+> wording alone.
+>
+> Opinions?
+
+As indicated above, I would prefer to get rid of the "is always True" phrase
+somehow.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 10, 2011 3:32 PM
+
+OK, "is always True" --> "always remains True", and "type" --> "subtype",
+resulting in:
+
+ NOTE: Similarly to constraints, a Static_Predicate always remains True for
+ all objects of the subtype, except in the case of uninitialized variables
+ and other invalid values. A Dynamic_Predicate, on the other hand, is checked
+ as specified above, but can become False at other times. For example, the
+ predicate of a record is not checked when a subcomponent is modified.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011 11:18 PM
+
+...
+> OK, "is always True" --> "always remains True", and "type"
+> --> "subtype", resulting in:
+
+I've inserted this into the "master" AI.
+
+> NOTE: Similarly to constraints, a Static_Predicate always remains True for all
+> objects of the subtype, except in the case of uninitialized variables and other
+> invalid values. A Dynamic_Predicate, on the other hand, is checked as specified
+> above, but can become False at other times. For example, the predicate of a
+> record is not checked when a subcomponent is modified.
+
+But I have a nit-pick: I've always found it strange that this note starts with
+"Similarly". It's jarring, because that is the sort of sentence that you'd
+expect in the middle of a paragraph, not starting one. And you have to read
+halfway through before you find out what it is about. There is also a mismatch
+between the plural "constraints" and the singular "a Static_Predicate". I
+haven't mentioned it before because I didn't have a great idea for a
+replacement.
+
+Perhaps:
+
+ NOTE: A Static_Predicate always remains True for all objects of the subtype,
+ except in the case of uninitialized variables and other invalid values; this
+ is similar to the behavior of a constraint. A Dynamic_Predicate, on the other
+ hand, is checked as specified above, but can become False at other times. For
+ example, the predicate of a record is not checked when a subcomponent is
+ modified.
+
+Or more informal:
+
+ NOTE: Like a constraint, a Static_Predicate always remains True for all
+ objects of the subtype, except in the case of uninitialized variables and
+ other invalid values. A Dynamic_Predicate, on the other hand, is checked as
+ specified above, but can become False at other times. For example, the
+ predicate of a record is not checked when a subcomponent is modified.
+
+Or:
+
+ NOTE: A Static_Predicate, like a constraint, always remains True for all
+ objects of the subtype, except in the case of uninitialized variables and
+ other invalid values. A Dynamic_Predicate, on the other hand, is checked as
+ specified above, but can become False at other times. For example, the
+ predicate of a record is not checked when a subcomponent is modified.
+
+[or replace "like a constraint" with "similar to a constraint" to be a bit more
+formal.]
+
+I think I like the last best - it puts the most important thing first, but still
+leaves the constraint part up front. A few more commas than I like, though. Any
+thoughts??
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 10, 2011 2:51 PM
+
+> When the Dynamic Semantics calls for a check of a value against a
+> Static_Predicate, the check may be omitted if every value that obeys
+> the Static_Predicates of the nominal subtype of the value also obeys
+> the Static_Predicate being checked against.
+
+Do we need any permission at all here?
+
+With Static_Predicates, the check either passes or fails, but it cannot have
+other side effects.
+
+Dynamic_Predicates are different (removing a dynamic predicate check would
+indeed require explicit permission) but we are not discussing those here (as of
+today - see previous version of the AI).
+
+Thus, do we need an explicit permission to omit a check which can only fail in
+the case of an invalid value? We don't have such an explicit permission for a
+constraint check (do we?); it just falls out from the rules for dealing with
+invalid values.
+
+How is the situation here any different?
+
+P.S. I like your treatment of "is statically compatible".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 10, 2011 3:00 PM
+
+> How is the situation here any different?
+
+I would be very happy to get rid of that para, and put something in the AARM,
+like:
+
+ Static_Predicate checks can be removed even in the presence
+ of potentially invalid values, just as contraint checks can
+ be removed.
+
+> P.S. I like your treatment of "is statically compatible".
+
+Good to know. I rewrote it about 50 times before I was satisfied!
+
+****************************************************************
+
+From: Steve Baird
+Sent: Thursday, February 10, 2011 3:13 PM
+
+Sounds good to me (now that we are only talking about static predicates).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 10, 2011 3:17 PM
+
+I don't think we want this permission.
+This is a very complicated area, and compilers have different strategies for
+dealing with invalid values. Omitting such a check presumes that doing so is
+consistent with the overall strategy of not allowing an invalid value to send
+things into erroneous land. For example, if the compiler is making assumptions
+elsewhere that a particular object satisfies the predicate, and the execution
+would be erroneous if that turns out to be false, then it had better not
+eliminate checks in certain cases.
+
+You might be able to derive that even in the presence of this permission, but
+this permission sounds pretty much like a blanket permission, and I am fairly
+sure that with AdaMagic's approach to handling invalid values, things would go
+haywire if we "obeyed" the implementation permission.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 10, 2011 3:48 PM
+
+> I don't think we want this permission.
+
+Fine with me!
+
+No such permission can be necessary in the Standard, because:
+
+ - If you want the utmost efficiency, you can always turn
+ off the checks by using Assertion_Policy.
+
+ - If you want something in between super-efficient and full-checking,
+ tell your friendly neighborhood compiler writer to implement
+ an impl-def policy (or a mode switch) that does what you want.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011 11:31 PM
+
+> You might be able to derive that even in the presence of this
+> permission, but this permission sounds pretty much like a blanket
+> permission, and I am fairly sure that with AdaMagic's approach to
+> handling invalid values, things would go haywire if we "obeyed" the
+> implementation permission.
+
+I agree that we don't want the permission -- because it isn't necessary.
+
+But this comment confuses me. This is an Implementation PERMISSION -- no one is
+forcing you to follow it. If omitting it screws up your object validity model,
+then *don't do that*.
+
+It would be different if there was some requirement to omit the check, but there
+is no such thing here.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011 11:33 PM
+
+I've removed the permission from the "master copy" of the AI.
****************************************************************
Questions? Ask the ACAA Technical Agent