CVS difference for ais/ai-00269.txt

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

--- ais/ai-00269.txt	2001/09/19 00:04:39	1.2
+++ ais/ai-00269.txt	2001/09/21 01:57:44	1.3
@@ -1,4 +1,4 @@
-!standard  4.09 (29)                                   01-09-18  AI95-00269/02
+!standard  4.09 (29)                                   01-09-20  AI95-00269/03
 !class binding interpretation 01-02-22
 !status work item 01-05-25
 !status received 01-03-23
@@ -63,27 +63,25 @@
 static in the instance. However, we need to be careful. We do not want to
 require exact evaluation for expressions static because of a formal object
 inside of the generic unit, because that would interfere with generic sharing.
-We also do not want to trigger the rounding rule of 4.9(38). Note that
-generic formal objects cannot be used in a context where a static expression is
-required inside of the generic, as legality rules are checked in the generic
-unit based on the properties of the formal (see 12.3(11)). Thus, any such
-use would be illegal in the generic unit.
-
-!corrigendum 4.09(24)
-
-@drepl
-A @i<static constant> is a constant view declared by a full constant
-declaration or an @fa<object_renaming_declaration> with a static nominal
-subtype, having a value defined by a static scalar expression or by a
-static string expression whose value has a length not exceeding the maximum
-length of a @fa<string_literal> in the implementation.
-@dby
-A @i<static constant> is a constant view declared by a full constant
-declaration, an @fa<object_renaming_declaration> with a static nominal
-subtype, or generic formal object of mode @b<in> declared in an instance and
-used outside of the instance having a value defined by a static scalar
-expression or by a static string expression whose value has a length not
-exceeding the maximum length of a @fa<string_literal> in the implementation.
+We also do not want to trigger any of the other rules of 4.9(34-38).
+All of these would require evaluating the expression when the generic is
+instantiated, which would introduce a body dependence.
+
+Note that generic formal objects cannot be used in a context where a static
+expression is required inside of the generic, as legality rules are checked
+in the generic unit based on the properties of the formal (see 12.3(11)).
+Thus, any such use would be illegal in the generic unit.
+
+!corrigendum 4.09(37)
+
+@dinsa
+The last two restrictions above do not apply if the expected type is a
+descendant of a formal scalar type (or a corresponding actual type in an
+instance).
+@dinst
+If a static expression appears in an instance body and the expression is
+non-static in the generic body, then none of the legality rules for static
+expressions apply to the expression in the instance.
 
 !ACATS test
 
@@ -1074,3 +1072,187 @@
 for (2) dug up (1) :-)
 
 ****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, September 19, 2001 10:18 AM
+
+> A @i<static constant> is a constant view declared by a full constant
+> declaration, an @fa<object_renaming_declaration> with a static nominal
+> subtype, or generic formal object of mode @b<in> declared in an instance and
+> used outside of the instance having a value defined by a static scalar
+> expression or by a static string expression whose value has a length not
+> exceeding the maximum length of a @fa<string_literal> in the implementation.
+
+I don't think that "used outside of the instance" works, because a generic
+formal object of mode in is never usable outside of the instance.  It can be
+used in another declaration, which is itself exported by the instance (e.g. B1
+is used in the declaration of C1 above).  I suggest removing "and used outside
+of the instance".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, September 19, 2001 10:31 PM
+
+I told you I wasn't happy with the wording. :-)
+
+However, removing "and used outside the instance" causes the problem of exact
+evaluation inside the generic unit instance to reappear. (Well, you would say
+it was never gone.)
+
+The issue is that inside the instance, anything these things touch need to be
+treated if they are non-static, and outside the instance, those expressions
+must be static. For generic sharing reasons, we do not want to require exact
+evaluation of these expressions, especially in the generic body. (Other
+legality rules are checked in the generic unit, so those rules are not a
+problem.)
+
+The problem is that the current wording for staticness doesn't have an
+provision for a "view" that is static and one that is not. That makes it
+very difficult to write this rule, which presumably is why it was left out
+of Ada 95 in the first place. It also shows why the Ada 83 rule was a mistake
+ -- but that's irrelevant.
+
+Given that my last attempt to do this failed, I think the most likely fix would
+be to try to change 4.9(33) to except expressions that are derived for a
+generic formal object from the exactness requirement. However, I can't think
+of any way to describe an expression that might derive from a generic formal
+object.
+
+Well, OK, I just had a rather goofy idea. Does the following work (to replace
+the second sentence of 4.9(33):
+
+This evaluation is performed exactly, without performing Overflow_Checks,
+unless the expression is in an instance and the expression is non-static in the
+generic.
+
+This describes operationally the rule we want. Does this work??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 20, 2001 10:11 AM
+
+We should look at paragraphs 33-37 together.  37 already talks about
+generic formal types.  It would seem we should somehow work
+the generic formal object and generic formal type rules together.
+
+On the other hand, are we presuming that the *spec* of an instance
+is shared?  I thought that was essentially impossible in Ada 95.
+Why can't the spec of an instance use exact evaluation?
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, September 20, 2001 2:00 PM
+
+I was puzzled by this too.  Evidently we don't want to require exact
+evaluation in bodies, but in specs it seems innocuous.  Sharing specs in Ada
+95 is close to impossible, because of all the rechecking that has to be done
+on instances.  This is one of the reasons why we got rid of shared generics,
+btw: we used to share specs in Ada 83, and this model was hopelessly broken
+by Ada 95.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 20, 2001 8:48 PM
+
+Tucker said:
+
+On the other hand, are we presuming that the *spec* of an instance
+is shared?  I thought that was essentially impossible in Ada 95.
+Why can't the spec of an instance use exact evaluation?
+
+Pascal said:
+
+I was puzzled by this too.  Evidently we don't want to require exact
+evaluation in bodies, but in specs it seems innocuous. Sharing specs in Ada
+95 is close to impossible, because of all the rechecking that has to be done
+on instances.  This is one of the reasons why we got rid of shared generics,
+btw: we used to share specs in Ada 83, and this model was hopelessly broken
+by Ada 95.
+
+And I reply:
+
+Rechecking is a red herring; what determines whether or not something can be
+shared is the code generation. And clearly there is no need to worry about the
+code generated if the instantiation will be illegal anyway. So that isn't a
+reason that generic specs cannot be shared.
+
+Indeed, you pretty much have to share specs in order to (always) share bodies;
+the data layout of the spec has to be the same for every instantiation, or the
+code to implement the body is laughable. That means that the majority of the
+elaboration code is also always the same: so why not share it?
+
+What we do for those few rules where "assume-the-best" has a code generation
+impact is to treat the item as a "hidden" generic formal. For instance, for
+tagged types declared in the specification of a generic unit, we generate a tag
+at instantiation time, then pass it as a generic formal to the generic unit.
+
+My objection was to adding another case where this hoop-jumping was necessary.
+However, that is moot. I realized on the way home last night that the rule I
+proposed was wrong: it would poison outside expressions by eliminating the
+requirement that their evaluation be exact. Thus the rule has to say "instance
+body". Indeed, Janus/Ada does use exact evaluation of static expressions in an
+instance spec -- but the result of that evaluation is not available in the
+generic. (Oddly, it only does so for integer types; perhaps to avoid the
+pathologies of exact evaluation for float types.) Generally, it doesn't matter:
+you'll get the same answer either way.
+
+I don't think this is a particular hardship, as I think any program that could
+tell the difference is a pathology, and I don't think that the ACATS will be
+testing it. :-) Janus/Ada has always behaved this way (back to Ada 83) and I
+don't think that anyone ever has complained. In the absence of a complaint
+backed up by $$$, it's likely to continue to behave that way.
+
+Tucker said:
+
+We should look at paragraphs 33-37 together.  37 already talks about
+generic formal types.  It would seem we should somehow work
+the generic formal object and generic formal type rules together.
+
+And I respond:
+
+I don't see this. The formal type rule only applies to paragraphs 35 and 36, and
+always applies. While the formal object rules applies to all of paragraphs 33 to
+36, but only in an instance body. Trying to merge them would seem to either
+require a significant change to the formal type rules (and they're not broken!),
+or some really convoluted wording.
+
+A safer alternative to my previous wording would be something like:
+
+If a static expression is in an instance body and the expression is non-static
+in the generic body, then none of the legality rules for static expressions
+apply in the instance.
+
+AARM Ramification Annotation: This means, among other things, that exact
+evaluation is not required for these expressions. Note that any rules which
+require a static expression must have been checked when the generic body was
+compiled, and would have made the body illegal for any expressions which trigger
+this rule, so the fact that these would not be checked in the instance is
+irrelevant. (All legality rules involving static expressions not found in 4.9
+are those that require some expression to be static.)
+
+AARM Discussion Annotation: Such expressions depend on generic formal object
+parameters. In order to allow generic sharing, we do not want to require the
+evaluation of such expressions when the generic is instantiated (as this would
+introduce a dependence on the body).
+
+
+Is this better??
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 20, 2001 8:50 PM
+
+Oops, this is still slightly wrong. Try:
+
+If a static expression is in an instance body and the
+expression is non-static in the generic body, then none of
+the legality rules for static expressions apply to the expression in the
+instance.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent