CVS difference for ai05s/ai05-0153-1.txt
--- ai05s/ai05-0153-1.txt 2010/11/18 07:01:34 1.12
+++ ai05s/ai05-0153-1.txt 2012/02/04 09:07:38 1.13
@@ -60,13 +60,13 @@
Subtype_Predicate
This aspect shall be specified by an expression.
The expected type for the expression is any boolean type.
- A Subtype_Predicate may be specified on a type_declaration
- or a subtype_declaration; if none is given, an implicit
+ A Subtype_Predicate may be specified on a type_declaration
+ or a subtype_declaration; if none is given, an implicit
"with Subtype_Predicate => True" is assumed.
-
+
Legality Rules
-
-Within the expression of a Subtype_Predicate aspect_specification
+
+Within the expression of a Subtype_Predicate aspect_specification
for a composite type C or an access to a composite type C, the only components
of C referenced shall be discriminants, and a name that denotes
the current instance of the (sub)type shall be used only as a prefix (including
@@ -75,7 +75,7 @@
First, Last, or Range.
Static Semantics
-
+
The /predicate of a subtype/ is defined as follows:
- For a (first) subtype defined by a derived type declaration, the
@@ -5022,3 +5022,601 @@
I'll take that as a "yes".
****************************************************************
+
+From: Robert Dewar
+Date: Sunday, September 26, 2010 5:38 AM
+
+It seems plain horrible that 'First and 'Last are legal for a discrete type with
+a predicate so that as noted in the RM
+
+ S'First in S
+
+can be False.
+
+This is language lawyer sophistry in my opinion.
+What possible use are 'First and 'Last if they give blatantly wrong results? If
+you don't allow
+
+ for J in S loop ...
+
+it is plain silly and dangerous to allow
+
+ for J in S'First .. S'Last ...
+
+If I have to, I will implement this as described, but for sure I will generate
+loud warnings with no special way to suppress them for these obviously wrong
+usages.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Sunday, September 26, 2010 10:25 AM
+
+We had some serious battles about this one.
+You should read the ARG minutes in any case.
+It might shed some light on the deliberations.
+I agree the final answer is not terribly satisfying.
+We may need to have another go-round on what to do with these guys with relation
+to 'first, 'last, use in case statements, etc. It is not a simple problem...
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, September 26, 2010 10:45 AM
+
+For me, I would like to see ONE example where it is useful to apply First or
+Last to such a type.
+
+Anyway, for now I think I will consider it illegal (that may be the best way to
+dig up such an example, and I don't count some arbitrary ACATS example as
+meeting that requirement).
+
+What bugs me here, is that for me, the original requirement was non-contiguous
+enumeration types.
+
+I get told, oh, this is a subset of the amazing predicate feature
+
+OK, don't need the amazing predicate feature, but if it will do what I want,
+fine.
+
+But then I discover it doesn't do what I want :-(
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, September 26, 2010 5:43 AM
+
+I am having trouble seeing what rule prohibits discrete subtype names as case
+choices if there is a predicate present.
+
+If this is allowed and ignores the predicate, that's plain horrible, even worse
+than allowing First/Last.
+
+If it is not allowed at all, that's plain horrible, since it means predicates
+are useless for (to me) their main purpose, static non-contiguous enum subtypes.
+
+If either of these is the case, I would be inclined to implement (under the GNAT
+language extension switch (*) if necessary), a recognition of a predicate as
+static if it is a membership test of the form
+
+ typename IN ...
+
+where ... are all static choices (and of course can use the extended syntax), so
+that
+
+ type R is (R, G, Y, O, B);
+
+ subtype RBG is R with
+ RBG in R .. G | B;
+
+would define RBG as having a static predicate, and thus be usable in case
+statements.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, September 26, 2010 5:47 AM
+
+what does it mean for two subtypes to have the "same" predicate.
+
+Are these the same
+
+ with Predicate => X = A or else X = B;
+
+ with Predicate => X = B or else X = A;
+
+answer, I hope, of course not, though if you introduce the notion of static
+predicates, then you have a clear notion of the set of values and hence of the
+idea of a predicate's effect and you can compare effects.
+
+Are these the same
+
+ with Predicate => (X.test);
+
+ with Predicate => test;
+
+where X is the package containing test?
+
+i.e. is there some notion of conformance checking. If so, what about inherited
+predicates?
+
+I really think we should say that two subtypes do not match if either has a
+predicate unless they are the same subtype.
+
+Perhaps the rules do say that, but I don't read them that way clearly.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, September 27, 2010 3:21 PM
+
+...
+> What bugs me here, is that for me, the original requirement was
+> non-contiguous enumeration types.
+>
+> I get told, oh, this is a subset of the amazing predicate feature
+>
+> OK, don't need the amazing predicate feature, but if it will do what I
+> want, fine.
+>
+> But then I discover it doesn't do what I want :-(
+
+This is not really true. What you want is set constraints (see AI05-0153-2 for a
+proposal). I created the predicate AI to show how they don't really work so as
+to justify the more complex features proposed in AI05-0153-2. However, not all
+of the ARG seems to understand this and the predicates were what went forward.
+
+The predicates cannot do everything that a set constraint can (in particular, a
+predicate cannot be static, so it can't be used in a case statement, while a set
+constraint is *required* to be static, so it of course can be). It's not
+possible in general to have static predicates (there was some e-mail in the past
+on why). If you need staticness, you need set constraints, period.
+
+Also note that 'First and 'Last have to be defined (they don't have to be usable
+of course) because the model of values for Ada subtypes is based on the 'First
+and 'Last values. It isn't possible to invent some alternative that doesn't use
+'First and 'Last since the predicate expression can be arbitrary and could have
+side-effects and other nasties. Set constraints define 'First and 'Last for this
+reason (but these are defined so that 'First and 'Last always belong to the set
+unless the set is null). It probably would be possible to have a separate value
+model for set constraints but it didn't seem worth it.
+
+I think you need to take a really serious look at the set constraint proposal to
+see if that better meets your needs; if so, you need to tell us before it is too
+late for this go-round.
+
+P.S. Can you tell that I am not happy with the predicate proposal, either??
+;-)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, September 27, 2010 5:54 PM
+
+> The predicates cannot do everything that a set constraint can (in
+> particular, a predicate cannot be static, so it can't be used in a
+> case statement, while a set constraint is *required* to be static, so
+> it of course can be). It's not possible in general to have static
+> predicates (there was some e-mail in the past on why). If you need
+> staticness, you need set constraints, period.
+
+Actually it is just fine to have static predicates. What I implemented was that
+a predicate is static if it is stand alone (does not inherit anything), and is
+of the form of a set membership, where all choices are static. Then static
+predicates are allowed in case statements, but not non-static predicates. The
+*ONLY* use of the staticness in predicates is wrt case statements, so I don't
+need "static predicates in general", just this one case.
+
+> Also note that 'First and 'Last have to be defined (they don't have to
+> be usable of course) because the model of values for Ada subtypes is
+> based on the 'First and 'Last values. It isn't possible to invent some
+> alternative that doesn't use 'First and 'Last since the predicate
+> expression can be arbitrary and could have side-effects and other nasties.
+
+Who cares about side effects in predicate expressions, I just don't see your
+point here at all.
+
+> Set constraints
+> define 'First and 'Last for this reason (but these are defined so that
+> 'First and 'Last always belong to the set unless the set is null). It
+> probably would be possible to have a separate value model for set
+> constraints but it didn't seem worth it.
+
+The point is that you should simply not be allowed to reference 'First and 'Last
+attributes, if you need to define them for some descriptive reason (I don't see
+it), fine, but you should not allow explicit references.
+
+> I think you need to take a really serious look at the set constraint
+> proposal to see if that better meets your needs; if so, you need to
+> tell us before it is too late for this go-round.
+
+I looked, I *MUCH* prefer the predicate proposal with a bit of tweaking, to
+eliminate First/Last and to allow the limited form
+
+> P.S. Can you tell that I am not happy with the predicate proposal, either??
+> ;-)
+
+But your alternative is much too limiting, and I don't think you should use my
+suggestions for improving the predicate proposal as an excuse for trying to push
+the set constraint proposal, which I think is dead at this stage for lack of
+support (you certainly can't get support from me :-))
+
+****************************************************************
+
+From: Tucker Taft
+Date: Monday, September 27, 2010 3:56 PM
+
+> ... Also note that 'First and 'Last have to be defined (they don't
+> have to be usable of course) because the model of values for Ada
+> subtypes is based on the 'First and 'Last values...
+
+One possible way to "solve" the S'First and S'Last problem is to define them as:
+
+ S'(S'First) and S'(S'Last)
+
+That is, you apply the predicate check to the value, and Constraint_Error is
+raised if they don't satisfy it.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, September 27, 2010 6:12 PM
+
+I suppose, I would just not allow explicit use of them in a program, rather than
+give them useless definitions! If you want S'Base'First and S'Base'Last, you can
+reference them, if you want the strange effect Tuck suggests you can write
+
+ S'(S'Base'First)
+
+:-)
+
+I don't mind if I have to implement them, I will just generate a warning that
+they are useless and almost certainly represent bugs in the program.
+
+****************************************************************
+
+From: Bob Duff
+Date: Monday, September 27, 2010 6:32 PM
+
+> One possible way to "solve" the S'First and S'Last problem is to
+> define them as:
+>
+> S'(S'First) and S'(S'Last)
+>
+> That is, you apply the predicate check to the value, and
+> Constraint_Error is raised if they don't satisfy it.
+
+That's a reasonable idea.
+
+I still think I prefer Robert's idea: define "staticness"
+somehow, and disallow direct references to 'First, 'Last and 'Range. Or, we
+could allow 'First only in the static case, and make it mean "the smallest value
+that obeys the predicate" (taking care of the case where the range is empty, or
+no value obeys the predicate).
+
+The one case where disallowing 'First won't quite work is for a generic formal
+subtype -- we don't know if it has a predicate. That's OK, we can do the usual
+kludge that preserves the letter of the "contract model" law, while violating
+the spirit, as usual.
+
+Randy is correct that the CONCEPT of 'First and 'Last need to be there, because
+we're going to be checking values against that range (in addition to checking
+the predicate). But Robert's idea of outlawing references to those attributes
+makes good sense -- it's quite similar to the fact that you can't say
+"array(subtype_with_predicate) of ...".
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, September 27, 2010 6:41 PM
+
+> The one case where disallowing 'First won't quite work is for a
+> generic formal subtype -- we don't know if it has a predicate. That's
+> OK, we can do the usual kludge that preserves the letter of the
+> "contract model" law, while violating the spirit, as usual.
+
+Let's remember that the idea of the generic contract model is that you write a
+generic and if it compiles OK, you are guaranteed that it will work for any
+allowed instantiation.
+
+There is no point in getting so fanatic over this model that we rig up things to
+compile, but the result is useless.
+
+After all I suppose that we could say that if you specify a size clause in a
+generic, it's legal even if inapplicable, and raises Program_Error at run time,
+but that would NOT be useful, though it would preserve the letter of the GCM.
+Instead we make the instantiation illegal, considering rep clauses to be a
+special case, I don't see it as so terrible to take the same view of the
+Predicate attribute :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, September 27, 2010 6:58 PM
+
+> After all I suppose that we could say that if you specify a size
+> clause in a generic, it's legal even if inapplicable, and raises
+> Program_Error at run time, but that would NOT be useful, though it
+> would preserve the letter of the GCM.
+> Instead we make the instantiation illegal, considering rep clauses to
+> be a special case, I don't see it as so terrible to take the same view
+> of the Predicate attribute :-)
+
+We surely do not want to make instantiations of generics with subtypes including
+a predicate illegal - that would make doing I/O impossible for such types. And
+I'm dubious that there is any value at all to preventing the use of 'First at
+all in a generic: the value has to be well-defined, so there is no semantic
+problem with allowing it, only a methodological one. We don't use the
+Program_Error trick for methodological checks, because it can only be annoying,
+not valuable.
+
+So I would simply allow 'First on generic formals with the appropriate
+definition: if that value is not covered by the predicate, you might get
+Constraint_Error, but so what? That's better than getting Program_Error even
+when everything is OK.
+
+(Honestly, I don't see any value to preventing the use of 'First. The problem is
+with the range S'First .. S'Last, which isn't meaningful for an S with a
+predicate. But since the range is of the base type (which has no predicate) - it
+is well defined. We should have S range <anything> be illegal, though, for the
+same reasons we don't allow array indexes. Not sure if we did that.)
+
+****************************************************************
+
+From: Robert Dewar
+Date: Monday, September 27, 2010 7:22 PM
+
+> We surely do not want to make instantiations of generics with subtypes
+> including a predicate illegal - that would make doing I/O impossible
+> for such types. And I'm dubious that there is any value at all to
+> preventing the use of 'First at all in a generic: the value has to be
+> well-defined, so there is no semantic problem with allowing it, only a
+> methodological one. We don't use the Program_Error trick for
+> methodological checks, because it can only be annoying, not valuable.
+
+To me this is not methodological, it is pretty fundamental, 'First is just
+meaningless. I would like to see ONE program where it made sense! If you raise
+Program_Error, then it gives a clear basis for a warning in the instance ("will
+raise PE at run-time").
+
+> (Honestly, I don't see any value to preventing the use of 'First. The
+> problem is with the range S'First .. S'Last, which isn't meaningful
+> for an S with a predicate. But since the range is of the base type
+> (which has no
+> predicate) - it is well defined. We should have S range<anything> be
+> illegal, though, for the same reasons we don't allow array indexes.
+> Not sure if we did that.)
+
+Just because something is defined does not mean it is reasonable to include it
+in the language. But as I say, I can settle for a loud warning that you have
+written something meaningless.
+
+I don't see making S'First be equal to S'Base'First, if the latter is what you
+want. I do understand the unease at the generic case ... and for SURE you don't
+want to make instantiations of generics with subtypes including a predicate
+illegal, although if they DO use 'First and 'Last they most likely don't work
+right for such an instantiation, would be interesting to see counterexamples
+
+Anyway, 'First and 'Last are a minor annoyance, the business of using limited
+static forms in case statements is much more important.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Date: Tuesday, September 28, 2010 12:58 AM
+
+Hmmm... don't we have a similar problem with S'Succ and S'Pred?
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, September 28, 2010 9:31 AM
+
+S'Succ, S'Pred, S'Image, S'Value, S'Pos, S'Val, etc are all based on the *type*
+not the *subtype*. So they are unaffected by the whole subtype predicate
+business.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 28, 2010 9:58 AM
+
+I have always found that surprising, so have many users, who expect e.g. a
+constraint error of S'Succ (S'Last). Given these surprises, junk behavior of
+S'First and S'Last is of the same kind. So let's just make
+
+S'First = S'Base'First if there is a predicate and same for S'Last
+
+then I will give a warning for ANY of these attributes applied to a subtype with
+predicates.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, September 28, 2010 10:15 AM
+
+I don't understand the benefit of this. It seems even more misleading:
+
+ subtype Positive_Even is Positive
+ with Predicate => Positive_Even mod 2 = 0;
+
+ Positive_Even'First = -2billion?
+
+I would rather disallow use of 'First/'Last, raising Program_Error in a generic.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, September 28, 2010 10:18 AM
+
+... Or require that S'First and S'Last satisfy the predicate. The argument that
+that is more work for the user seems to be outweighed by all the complexity we
+are facing with the possibility that S'First not in S.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 28, 2010 10:31 AM
+
+> I don't understand the benefit of this. It seems even more
+> misleading:
+>
+> subtype Positive_Even is Positive
+> with Predicate => Positive_Even mod 2 = 0;
+>
+> Positive_Even'First = -2billion?
+
+Doesn't seem any worse than
+
+ Positive'Pred (0) = -1?
+>
+> I would rather disallow use of 'First/'Last, raising Program_Error in
+> a generic.
+
+I officially don't care, but don't want the bother about this minor issue to be
+used by Randy as a reason to try to undermine the proposal :-) :-)
+
+why is X'First any worse than a "non-working" X'Succ.
+Yes I know the misbehavior of Succ is documented, but in my experience it comes
+as a surprise to nearly all Ada programmers, and now this misbehavior is much
+more apparent when you have predicates.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 28, 2010 10:31 AM
+
+> ... Or require that S'First and S'Last satisfy the predicate. The
+> argument that that is more work for the user seems to be outweighed by
+> all the complexity we are facing with the possibility that S'First not
+> in S.
+
+Again, why go this far with First and Last when all the other predicates have
+similar surprising behavior.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 28, 2010 11:07 AM
+
+(running into interesting things implementing stuff :-))
+
+Consider
+
+package q is
+ type r is new integer;
+ subtype s is r;
+ type v is new s range 1 .. 10;
+ vv : v;
+ for s'value_size use 40;
+ for v'value_size use 48;
+end q;
+
+Does the type declaration for v freeze s?
+
+In GNAT the answer is no, is this right?
+
+> 1. package q is
+> 2. type r is new integer;
+> 3. subtype s is r;
+> 4. type v is new s range 1 .. 10;
+> 5. vv : v;
+> |
+> >>> warning: no more representation items for type
+> "v" defined at line 4
+>
+> 6. for s'value_size use 40;
+> 7. for v'value_size use 48;
+> |
+> >>> representation item appears too late
+>
+> 8. end q;
+
+As you see v is frozen but s is not.
+
+Now if this is a GNAT bug, it needs fixing
+
+If it is NOT a GNAT bug, then I point out that if s has a predicate, we MUST
+have v freeze s, because v inherits a predicate which could be used before s is
+frozen, and that can't be right (note that the predicate expression of the
+predicate for s is analyzed at the freeze point of s, which cannot be after the
+freeze point for v!)
+
+Are there other cases where the presence of predicates affects freezing rules
+(or are there any cases if the above is a GNAT bug).
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, September 28, 2010 11:09 AM
+
+> ... Or require that S'First and S'Last satisfy the predicate.
+
+You mean your earlier suggestion, where S'First does the check? I hope you're
+not suggesting to do the check on the subtype decl, because I think we want to
+allow:
+
+ subtype Even is Natural with Predicate => Even mod 2 = 0;
+
+without worrying about whether Natural'Last is even.
+
+****************************************************************
+
+From: Bob Duff
+Date: Tuesday, September 28, 2010 11:13 AM
+
+> > I don't understand the benefit of this. It seems even more
+> > misleading:
+> >
+> > subtype Positive_Even is Positive
+> > with Predicate => Positive_Even mod 2 = 0;
+> >
+> > Positive_Even'First = -2billion?
+>
+> Doesn't seem any worse than
+>
+> Positive'Pred (0) = -1?
+
+It seems much worse to me.
+
+Failing to raise an exception is a surprise, but much less dangerous than
+returning a wrong answer. I mean, Pred(0) really is -1.
+
+And suppose you started with:
+
+ subtype S1 is something range 1..100;
+ subtype S2 is S1;
+
+Then adding a predicate to S2 changes the value of S2'First?
+Better to make all occurrences of S2'First illegal.
+
+****************************************************************
+
+From: Robert Dewar
+Date: Tuesday, September 28, 2010 11:20 AM
+
+OK, I am convinced, I withdraw my idiotic suggestion about 'Base'First :-)
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, September 28, 2010 11:24 AM
+
+> You mean your earlier suggestion, where S'First does the check? I
+> hope you're not suggesting to do the check on the subtype decl,
+> because I think we want to allow:
+>
+> subtype Even is Natural with Predicate => Even mod 2 = 0;
+>
+> without worrying about whether Natural'Last is even.
+
+I *am* suggesting that the programmer should do the extra work when they define
+a subtype with a predicate to make sure that 'First and 'Last satisfy the
+predicate. This seems better than all the other problems we are now discussing.
+There will be relatively few subtype declarations with predicates of the above
+form, I predict, and making the definer of the subtype face up to the issue of
+S'First and S'Last at that point seems better than having a random user of the
+subtype need to worry about it.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent