CVS difference for ais/ai-00311.txt

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

--- ais/ai-00311.txt	2003/09/19 01:42:28	1.3
+++ ais/ai-00311.txt	2003/12/07 05:00:32	1.4
@@ -302,3 +302,246 @@
 I'm *certain* we don't want to follow this model here!
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 6, 2003  12:02 PM
+
+I think we discussed this once, but it just
+came up in a compiler problem I was diagnosing,
+and I can't remember the resolution.
+
+4.9 (static expressions, etc.) talks about
+"descendants of a formal scalar type" which does
+not include a formal derived type whose ancestor
+is scalar.  I think that is intentional, in general,
+since the base subtype of a scalar formal derived
+type is known, and will generally be static (since
+all base subtypes are static, except for
+those of "formal scalar types").
+
+Now the question comes up is whether the
+*constraint* of a scalar formal derived type
+is static, and just what it is.  It seems that
+it should be considered always nonstatic, since
+12.5.1 only requires that the actual be statically
+*compatible* with the ancestor.  This implies that
+the actual subtype range need not be the same as
+that of the ancestor; it can be a narrower range.
+
+Hence, given a formal derived type:
+
+   generic
+     type T is new Positive;
+     ...
+
+   T'Base is a static unconstrained subtype
+   T      is a nonstatic constrained subtype
+
+   T'Base'First is a static expression, = Positive'Base'First
+   T'First is nonstatic, but is known to be >= Positive'First
+
+Does that sound right?
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, October 6, 2003  12:10 PM
+
+Yes, that looks exactly right.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, October 6, 2003  1:40 PM
+
+I agree.
+
+If T'First were static, then what would its value be?
+Surely it can't be 1, because the Actual_Subtype'First
+might not be 1.
+
+And if T'First is nonstatic, then surely T is not a static subtype!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 6, 2003  11:13 PM
+
+I believe this is AI-311, which was on the agenda (Pascal had updated it),
+but not discussed. Please check it to see if it handles the case you're
+worried about.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 7, 2003  5:11 AM
+
+Now here is my next question.  What about
+static compatibility...:
+
+     generic
+        type T1 is new Positive;
+     package Gen1 is ...;
+
+     generic
+        type T2 is new Positive;
+     package Gen2 is
+        package Inst1 is new Gen1(T2);  -- legal?
+     end Gen2;
+
+Is this legal?  It would be nice, but the
+rules for static compatibility, as written, would
+probably say it was *not* legal, since T2 is not
+statically compatible with Positive, according
+to my reading of 4.9.1, since T2 has a non-static
+constraint (based on the earlier messages), and a non-static
+constraint can only be statically compatible if it
+statically matches the other constraint, and we know the
+constraint of T2 is not necessarily Positive'Range.
+
+On the other hand, we know that any actual type for T2
+must be statically compatible with T2's ancestor,
+i.e. Positive, so it seems like T2 ought to be
+a special case.  Namely, the constraint of
+a formal derived subtype should be considered statically
+compatible with its ancestor subtype (and anything
+that statically matches its ancestor subtype).
+
+So I think we have two holes: we need to specify that
+the constraint of a formal derived type is *not* static,
+but that it *is* statically compatible with its
+ancestor.  Alternatively, we could express it
+recursively, saying that the constraint of a formal
+derived subtype is statically compatible if the constraint
+of its ancestor subtype is statically compatible (that
+would be more flexible).  The same would *not* apply
+for static matching, presumably.
+
+By the way, this came up in real code written
+by a REAL programmer (guess who ... his initials
+are R.A.D. ;-).
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, October 7, 2003  8:11 AM
+
+> Is this legal?  It would be nice, but the
+> rules for static compatibility, as written, would
+> probably say it was *not* legal...
+
+I think this comes under the Robert Dewar rule that any silly ramification of
+the rules is wrong.  Can T2 be statically compatible with Positive on line 6,
+and not statically compatible with Positive on line 8?  That seems to stretch
+the definition of STATICALLY compatible completely out of shape.  I'm not all
+that sure that I like the implementation implications of such a rule in
+general, but I think that this is the only special case that has to be dealt
+with--a legality check in the defining instance of a derived (sub)type.  So
+subsequent checks can be made the way Tucker envisions.  (A generic formal type
+must be statically compatible with its parent subtype, so in later uses of the
+type, it is okay for the formal type to be used where it needs to be statically
+compatible with its original parent.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, October 7, 2003  11:06 AM
+
+Unfortunately, 311 doesn't really address the whole problem.
+It mostly talks about formal scalar types, rather than scalar
+formal derived types.  It also doesn't mention static compatibility.
+I think the "fix" for static matching looks good for both kinds of
+scalar formal types, but we also need a fix to static compatibility.
+
+As mentioned in my earlier note, I suggest we fix static compatibility
+by saying that the constraint of a scalar formal derived type is
+statically compatible with anything that its parent subtype is
+statically compatible with.
+
+We also need to add something to make clear that the constraint
+of a scalar formal derived type is not static.
+
+It seems reasonable to add both of these to AI-311.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 4, 2003  6:54 PM
+
+I agree about the static compatibility (well, actually I don't agree it is
+worth changing this, but certainly the AI doesn't cover it and it is worth
+discussion), but I don't have a clue why you think that a scalar formal derived
+type could have a static constraint given the wording proposed in the AI.
+
+The AI proposes to add after 4.9(31):
+
+  In any case, the constraint of a generic formal type is neither static nor
+  null.
+
+Certainly this covers a scalar formal derived type! This covers ANY generic
+formal type.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 4, 2003  10:06 PM
+
+> The AI proposes to add after 4.9(31):
+>
+>   In any case, the constraint of a generic formal type is neither static nor
+> null.
+
+This seems to be going too far and is gratuitously
+upward incompatible.  Why can't the constraint
+of a formal array type be static?  For a formal derived
+composite type, there seems no problem inheriting the
+staticness from the ancestor type.  It is only a formal
+derived scalar type that allows the constraints to differ
+between the ancestor and the actual, so that is the
+one we should be worrying about.
+
+> Certainly this covers a scalar formal derived type! This covers ANY generic
+> formal type.
+
+And it shouldn't.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 4, 2003  11:15 PM
+
+> This seems to be going too far and is gratuitously
+> upward incompatible.  Why can't the constraint
+> of a formal array type be static?
+
+I could probably come up with a number of reasons if I cared to think about it,
+but I don't right now.
+
+> For a formal derived
+> composite type, there seems no problem inheriting the
+> staticness from the ancestor type.  It is only a formal
+> derived scalar type that allows the constraints to differ
+> between the ancestor and the actual, so that is the
+> one we should be worrying about.
+
+Huh? The original problem of AI-311 was with a regular generic formal scalar
+type. Clearly this has to apply at a minimum to all generic formal types which
+are scalar. (That should be generally true in the RM - it's unfortunate that
+generic formal xxx type does not include generic derived types which are xxx,
+because they are implemented in exactly the same way, and have the same
+semantics except for additional operations. Any rule on generic formal xxx
+should also apply to generic formal derived xxx types, unless it has to do with
+primitive operations.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December 5, 2003  7:06 AM
+
+I wasn't debating that.  I was debating the blanket statement
+that *all* formal types, including access and composite
+types,  have non-static constraints.  That seems incompatible
+and unnecessary.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent