CVS difference for ai05s/ai05-0153-2.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0153-2.txt

--- ai05s/ai05-0153-2.txt	2009/10/29 04:05:05	1.4
+++ ai05s/ai05-0153-2.txt	2009/11/04 00:56:04	1.5
@@ -1,4 +1,4 @@
-!standard  3.2.2(7)                                   09-10-26    AI05-0153-1/02
+!standard  3.2.2(7)                                   09-10-29    AI05-0153-2/04
 !class Amendment 09-10-16
 !status work item 09-10-16
 !status received 09-10-16
@@ -29,7 +29,29 @@
 List scalar constraints:
+Modify 3.2(7/2):
+The set of possible values for an object of a given type can be subjected to a
+condition that is called a *constraint* (the case of a null constraint that specifies
+no restriction is also included); the rules for which values satisfy a given kind
+of constraint are given in 3.5 for range_constraints {and list_constraints},
+3.6.1 for index_constraints, and 3.7.1 for discriminant_constraints. The set of
+possible values for an object of an access type can also be subjected to a condition
+that excludes the null value (see 3.10).
+[Editor's note: I'm dubious that there even should be a list of constraint types
+in this paragraph and the following one, because it ignores the obsolescent kinds
+of constraints (meaning it is a lie), and is a clear maintenance hazard (as I just
+happened across these paragraphs looking for something else, otherwise I never would
+have noticed them).]
+Modify 3.2(9/2):
+A subtype is called an unconstrained subtype if its type has unknown discriminants,
+or if its type allows range, {list,} index, or discriminant constraints, but the subtype
+does not impose such a constraint; otherwise, the subtype is called a constrained subtype
+(since it has no unconstrained characteristics).
 Replace 3.2.2(6) with:
 scalar_constraint ::=
@@ -74,6 +96,11 @@
 are null ranges. A scalar subtype is *discontiguous* if it has a discontiguous
+[Editor's Note: Steve Baird suggests that this concept be called "complex" or some
+other such name as "discontiguous" is confusing in the case of null ranges. That's
+a reasonable point; but the best term isn't obvious and the wording changes needed
+are purely search-and-replace, so I left it for discussion.]
 AARM Ramification: We require staticness for the discrete_choices, so the lower and
 upper bounds can be determined at compile-time (we don't want to have to do a
 complex calculation to determine S'First). This also allows us to make legality
@@ -161,7 +188,7 @@
 Add after 3.5(9):
-The elaboration of a list_constraint consists of the elababoration of the
+The elaboration of a list_constraint consists of the elaboration of the
 discrete_choice_list. Expressions and discrete_ranges of the
 discrete_choice_list are evaluated in an arbitrary order, and are converted to
 the type of the subtype_mark of the subtype_indication which contains the
@@ -313,7 +340,14 @@
 We might benefit from defining a term for "discriminant_constraint that contains
 at least one discrete_range". I considered "mutable subtype" for that, but the
-term is more general than the use. So I didn't define a term at all.]
+term is more general than the use. No other good ideas leapt out at me, so I didn't
+define a term at all.
+Steve Baird suggests converting the normative sentence above into a series of bullets,
+which would be much more readable. I didn't take that suggestion because this sentence
+is dead center in the middle of a paragraph, and his suggestion provided no sane way to
+deal with the implicit spliting of that single paragraph in many. If we follow that
+approach, the entire paragraph should be reordered.]
 Modify 3.3(23.2/3): [Added by AI05-0008-1]
@@ -348,7 +382,7 @@
 is constrained with a range or subtype; we don't want to allow changing the
 discriminant to some other value within the range or subtype. Otherwise, we
 would add all of the implementation problems of mutable discriminants to any
-object with a constraint that *might* contain a range or subtype. 
+object with a constraint that *might* contain a range or subtype.
 End AARM Reason.
 [Editor's note: We didn't check for null ranges in discriminant_constraints,
@@ -695,7 +729,7 @@
 constraint containing a subtype allows one of a set of discriminants, it makes sense
 that when an object is created using that constraint, a random value of the set is used
 to set the discriminants. We arbitrarily choose the first value simply so that the value
-chosen is the same on all compilers. 
+chosen is the same on all compilers.
 One nice result of changing the definition of definiteness slightly is that it avoids
 generic complications. Whether a generic formal is definite or indefinite is a matter
@@ -1080,5 +1114,113 @@
 > bad news and definitely more trouble than they are worth.
 And I had my heart set on using discontiguous entry families ...
+From: Bob Duff
+Date: Tuesday, November 3, 2009  1:16 PM
+Do we have an AI on user-defined constraints?  If not, shall I write one up?
+I think user-defined constraints are far more useful than invariants, as defined
+here. (I'm not sure why invariants can't behave as user-defined constraints, but
+so I've been told. I guess it's just a terminology issue.)
+From: Gary Dismukes
+Date: Tuesday, November 3, 2009  1:26 PM
+There's already AI05-153-1 (Subtype predicates), and the competing AI05-153-2
+(Discontiguous scalar constraints and extended discriminant constraints).
+Those came out of Randy's proposal to have user-defined constraints, so we
+probably don't need another one.
+From: Bob Duff
+Date: Tuesday, November 3, 2009  1:39 PM
+Ah, thanks for the info.  I was using the wrong search terms!
+These are on the agenda, so I'll come to the meeting prepared to argue in favor.
+From: Robert Dewar
+Date: Tuesday, November 3, 2009  1:48 PM
+What I most want is non-contiguous subtypes, everything else is secondary. So I
+hope these fall out. Particularly in connection with membership tests, and set
+notation, these would be very useful, I don't necessarily want loops and arrays
+defined on these things, though given the crud with enumeration rep clauses, it
+probably doesn't add that much to implementation burdens to accomodate these
+(pretty useless) cases.
+From: Randy Brukardt
+Date: Tuesday, November 3, 2009  2:00 PM
+I suggest reading AI05-0153-2 (although, please wait until I post the latest
+version tonight). This proposes "list constraints" (essentially constraints to
+sets of values) and works out the wording and semantics needed.
+Loops are actually fall out naturally (the existing wording does exactly the
+right thing). Arrays, however, are impossible to implement. Imagine an array of
+a by-reference type, and then imagine slicing it with a non-contiguous discrete
+subtype. Yuck! So arrays are illegal/raise Program_Error for such subtypes.
+Anyway, this is all discussed in detail in the AI.
+General user-defined constraints don't work, unfortunately, because the
+constraints can't properly identify a value for object creation. (There are
+other problems as well with calling them "constraints".) I tried a solution
+using subtype predicates (that aren't constraints, but rather just something
+attached to the subtype), but that proposal made Steve ill (for various good
+reasons), so I don't have a lot of hope that the rest of the ARG will like it
+much, either.
+From: Bob Duff
+Date: Tuesday, November 3, 2009  2:02 PM
+> What I most want is non-contiguous subtypes, everything else is
+> secondary.
+Yes, I want non-contiguous subtypes of enum types.  I also want non-contiguous
+constraints applied to a discriminant like "Kind: Node_Kind".
+From: Randy Brukardt
+Date: Tuesday, November 3, 2009  2:14 PM
+That's exactly what is proposed in AI05-0153-2. But, as I suggested, wait until
+tomorrow to read it.
+From: Tucker Taft
+Date: Tuesday, November 3, 2009  3:45 PM
+I attempted to explain the difference between invariants and constraints in this
+AI [AI05-0146-1 - ED].  Read the "problem" section.
+The basic difference is that an invariant applies to all values of a (private)
+type, whereas a constraint is used to define a subset of the values of some
+From: Robert Dewar
+Date: Tuesday, November 3, 2009  6:51 PM
+> Yes, I want non-contiguous subtypes of enum types.  I also want
+> non-contiguous constraints applied to a discriminant like "Kind: Node_Kind".
+Not clear what you have in mind, at least to me, can you give an example?

Questions? Ask the ACAA Technical Agent