CVS difference for ais/ai-00269.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00269.txt

--- ais/ai-00269.txt	2004/07/31 04:28:12	1.5
+++ ais/ai-00269.txt	2004/09/04 01:13:43	1.6
@@ -1504,3 +1504,190 @@
 
 ****************************************************************
 
+From: Gary Dismukes
+Sent: Wednesday, August 4, 2004  12:59 AM
+
+Randy wrote:
+>
+> OK, I'll bite. Clearly Some_Range'Last is static, and since static
+> expressions are evaluated exactly, and all of these contexts are
+> universal_integer contexts, I would expect them all to be legal.
+
+I would expect them to all be legal as well.
+
+> Of course, that's not quite right. The contexts for the first and last are
+> "any integer type". The middle context is universal_integer.
+
+(Actually the first and middle are "of any integer type" and the last
+one, the attribute clause, has an expected type of universal_integer.)
+
+> But that
+> doesn't matter. What does matter (something I realized before responding
+> above) is that the multiply has type Some_Range. That is a value of 60,000,
+> which is outside of the base range. But wait! There's an exception depending
+> on the expected type. So does that apply or not when the expected type is
+> "any integer type"? Dunno, but it hardly makes sense to make these cases
+> illegal.
+
+Right, the question is what "*the* expected type" is when an expression
+is "expected to be of any integer type".  I first thought that it would
+be the type that the expression ends up resolving to, but that would
+make the first two cases illegal, which is obviously undesirable.
+
+> Well, AI-269 needs to rewrite parts of 4.9 anyway, because its seriously
+> screwed up for generics. That was the *only* AI that wasn't revised in time
+> for the Palma meeting. *Everyone* one else got their homework done on time.
+> That AI was assigned to one Gary Dismukes, who ruined an otherwise perfect
+> record (children are no excuse! :-) :-). Anyway, given that you're going to
+> be rewriting that section anyway, I suggest just adding any other changes to
+> the same AI. That will save me work, and avoid future problems trying to
+> merge the changes.
+
+Addressing this as part of AI-269 seems odd to me, since it's really
+a different issue (the only thing they really have in common is that
+they both have to do with static expressions).  But I understand this
+would save you some work, which maybe is sufficient justification :)
+It still seems like this should be handled in a separate AI, but
+I'm willing to follow orders (even though I'm delinquent;-).
+
+Tuck wrote:
+>
+> I agree with Randy that when "any integer type" is expected,
+> we should treat this as equivalent to having universal_integer
+> as the expected type, and that for the purposes of 4.9(35),
+> the base range of universal_integer and for "any integer type"
+> should be considered unbounded.
+
+I agree it seems reasonable to make such contexts equivalent to
+having universal_integer as the expected type.  I think that
+should work, though a bit of study is needed to make sure it
+wouldn't cause problems with any other rules (probably not,
+but I'm not 100% sure).
+
+> It would seem worthwhile to revise 4.9(35) to make this explicit.
+> As far as I know, we never define the base range of
+> universal_integer, and I recommend we revise 4.9(35) so
+> we don't need to.
+
+Right, the base range of universal_integer is never defined.
+I'm not sure why it would be a problem to define it though,
+just saying that it includes the infinite set of integers
+(it wouldn't have a first and last of course, but I don't
+see offhand why that would matter).
+
+Bob Duff wrote:
+>
+> I think the intent was thast "any integer type" means the same thing as
+> "universal_integer".  (Also known as root_integer'Class, until a certain
+> "scope reduction" meeting!)  I presume universal_integer has the same
+> base range as root_integer, and that that base range is infinite.  I
+> don't know if the RM says that, but it seems obviously true.
+
+Actually the range of root_integer is Min_Int to Max_Int, it's not
+infinite.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, August 4, 2004  2:24 AM
+
+Gary Dismukes wrote:
+
+> Right, the question is what "*the* expected type" is when an expression
+> is "expected to be of any integer type".  I first thought that it would
+> be the type that the expression ends up resolving to, but that would
+> make the first two cases illegal, which is obviously undesirable.
+
+And therefore an incorrect interpretation by Robert's rule.
+
+By the way, we already fixed GNAT to allow all of these cases.
+
+> Actually the range of root_integer is Min_Int to Max_Int, it's not
+> infinite.
+
+And that's not a big enough range I am afraid, so let's make sure
+that the solution does not get stuck on this example.
+
+    type x is mod rec'size * 2 ** 64;
+
+should be allowed if rec is a one bit record, and Max_Int is likely
+to be 2**63-1.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Wednesday, August 4, 2004  9:38 AM
+
+Gary wrote:
+
+> Actually the range of root_integer is Min_Int to Max_Int, it's not
+               base range
+> infinite.
+
+OK, I see that rule now.  Doesn't that imply that the base range of
+universal_integer is also Min_Int..Max_Int?
+
+I think the point is to define when run-time calculations can overflow.
+Run-time calculations involving these types are pretty rare -- most
+expressions are static.
+
+Anyway, I still agree with Randy, Tuck, and Gary: the examples given
+should be legal.
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, August 4, 2004  11:53 AM
+
+Bob Duff wrote:
+>
+> Gary wrote:
+>
+> > Actually the range of root_integer is Min_Int to Max_Int, it's not
+> > base range infinite.
+>
+> OK, I see that rule now.  Doesn't that imply that the base range of
+> universal_integer is also Min_Int..Max_Int?
+
+No, that isn't implied as far as I can see.
+
+> I think the point is to define when run-time calculations can overflow.
+> Run-time calculations involving these types are pretty rare -- most
+> expressions are static.
+
+It certainly seems that nonstatic cases need to be limited to the range
+of root_integer, but I thought the intent was that static universal
+expressions could have a much larger magnitude.  Also, examples such
+as the one Robert gave would be illegal if universal_integer base range
+were limited to that of root_integer.
+
+> Anyway, I still agree with Randy, Tuck, and Gary: the examples given
+> should be legal.
+
+Good, sounds like there's general agreement on that point (at least
+I haven't heard any dissent:).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 27, 2004  7:02 PM
+
+Gary wrote (a while back):
+
+> Addressing this as part of AI-269 seems odd to me, since it's really
+> a different issue (the only thing they really have in common is that
+> they both have to do with static expressions).  But I understand this
+> would save you some work, which maybe is sufficient justification :)
+> It still seems like this should be handled in a separate AI, but
+> I'm willing to follow orders (even though I'm delinquent;-).
+
+I understand that the issue is different. But the real issue here is that
+you're going to need to tweak some delicate rules. If the rules that you
+tweak end up to be not interrelated, then feel free to create a new AI out
+of the new issue. But if they end up intertwined (which seems likely to me),
+I think we'd end up confusing ourselves more if we try to treat them
+separately. (We've certainly done that in other areas.) To help meet our
+schedule, I don't think we want any unnecessary confusion at this point.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent