CVS difference for ai05s/ai05-0147-1.txt
--- ai05s/ai05-0147-1.txt 2010/01/19 06:48:18 1.7
+++ ai05s/ai05-0147-1.txt 2010/01/21 05:13:18 1.8
@@ -1,4 +1,4 @@
-!standard 4.4(7) 10-01-18 AI05-0147-1/05
+!standard 4.4(7) 10-01-19 AI05-0147-1/06
!standard 4.5.7(0)
!standard 4.7(2)
!standard 4.7(3)
@@ -143,7 +143,7 @@
A condition is expected to be of any boolean type.
If a conditional_expression is expected to be of a type T, the expected type for
-each dependent_expression of a conditional_expression is T. If a
+each dependent_expression of the conditional_expression is T. If a
conditional_expression shall resolve to a type T, each dependent_expression
shall resolve to T.
@@ -165,10 +165,13 @@
of the dependent_expressions of the conditional_expression shall be dynamically
tagged, or none shall be dynamically tagged; the conditional_expression is
dynamically tagged if all of the dependent_expressions are dynamically tagged,
+is tag-indeterminate if all of the dependent_expressions are tag-indeterminant,
and is statically tagged otherwise.
[Editor's note: We don't try to define the type of the conditional expression;
-it gets complex when implicit conversions are involved.]
+it gets complex when implicit conversions are involved. There may not be a
+unique type that is identifiable (especially as dynamically tagged expressions
+might need to be converted to be classwide).]
Dynamic Semantics
@@ -7310,7 +7313,10 @@
dependent_expressions are dynamically tagged, and is statically tagged
otherwise.
-[We need this latter rule to be able to enforce 3.9.2(8); we don't want the parameter of a dispatching call to have mixed static and dynamic tagging. We could have written this in terms of dispatching calls instead, but 3.9.2(9/1) makes other uses of dyna
mically tagged expressions illegal.]
+[We need this latter rule to be able to enforce 3.9.2(8); we don't want the
+parameter of a dispatching call to have mixed static and dynamic tagging. We
+could have written this in terms of dispatching calls instead, but 3.9.2(9/1)
+makes other uses of dynamically tagged expressions illegal.]
The first rule is needed to avoid expressions with different types in the
different branches. (Note the we don't need to talk about "single types" here,
@@ -7332,7 +7338,8 @@
function ">" (A, B : Natural) return Some_Boolean;
if (if Cond then Var < 10 else Var > 20) then ... -- ">" is ambiguous;
- -- the fact that only one interpretation would pass the legality rule is irrelevant.
+ -- the fact that only one interpretation would pass the legality rule
+ -- is irrelevant.
I think this ambiguity is in keeping with the analogy to parens; the expression
would be ambiguous if written as statements:
@@ -7428,3 +7435,263 @@
Thanks for reading this lengthy discussion.
****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, January 19, 2010 11:12 PM
+
+> So we need slightly more complex wording:
+>
+> If a conditional_expression has an expected type T, the expected
+> type for each dependent_expression
+> of a conditional_expression is T. If a conditional_expression
+> shall resolve to a type T, each
+> dependent_expression shall resolve to T.
+
+"of a conditional_expression" => "of the conditional_expression".
+
+>
+> AARM To Be Honest: T in this rule could be any type in a class of
+> types (including the class of all
+> types), or (for the second rule) an anonymous access type (for
+> renames) or a universal type covering
+> some type (for qualified expressions).
+>
+
+I don't think that a TBH note is appropriate here (as opposed to explicitly saying what is really meant), but I agree that it's a judgment call.
+
+> Then we need some legality rules:
+>
+> Legality Rules
+>
+> If the expected type of a conditional_expression is any type in a
+> class of types (instead of a
+> particular type), all dependent_expressions of the
+> conditional_expression shall have the same type.
+
+
+Can we eliminate "if the expected type" test and replace the above with
+something like:
+
+ Given any two dependent_expressions of one conditional_expression,
+ either the types of the two expressions shall be the same or
+ one shall be a universal_type that covers the other.
+
+And now that we are talking about an arbitrary pair of dependent expressions, we
+can continue with more legality checks.
+
+ Furthermore, the two dependent_expressions shall agree with respect
+ to the properties of being statically tagged, dynamically tagged, and
+ tag indeterminant. A conditional expression is statically tagged
+ (respectively: dynamically tagged, tag indeterminant) if and only
+ if all of its dependent_expressions are.
+
+Actually, the second sentence probably needs to be moved to 3.9.2 - otherwise we
+are (implicitly at least) adding a "notwithstanding what 3.9.2 said about these
+definitions" here and that's undesirable.
+
+> If the expected type of a conditional_expression is a specific
+> tagged type, all of the dependent_expressions
+> of the conditional_expression shall be dynamically tagged, or
+> none shall be dynamically tagged; the
+> conditional_expression is dynamically tagged if all of the
+> dependent_expressions are dynamically tagged, and
+> is statically tagged otherwise.
+
+
+I think there may be a problem here with something like
+ (if cond then statically-tagged-expr else tag-indeterminant-expr) which is
+ addressed by my proposal above.
+
+>
+>
+> ---
+>
+> So, for the moment, I'm going to allow build-in-place for conditional
+> expressions.
+>
+
+Sounds right.
+
+Incidentally, I agree that it seems odd that we don't have a rule defining the
+type of a conditional expression. Even if the language definition doesn't need
+such a rule, I think that most compiler writers would find such a rule
+reassuring.
+
+If we need such a rule, perhaps something like
+ The type of a conditional expression is the unique element of the
+ set of dependent_expression types of the conditional_expression
+ which does not cover any other element of that set.
+
+, with an accompanying AARM argument for why this definition is well-defined (at
+least if no legality rules have been violated).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 19, 2010 3:47 PM
+
+Steve Baird writes:
+> Randy Brukardt wrote:
+> > So we need slightly more complex wording:
+> >
+> > If a conditional_expression has an expected type T, the expected
+> > type for each dependent_expression
+> > of a conditional_expression is T. If a conditional_expression
+> > shall resolve to a type T, each
+> > dependent_expression shall resolve to T.
+>
+> "of a conditional_expression" => "of the conditional_expression".
+
+OK.
+
+> > AARM To Be Honest: T in this rule could be any type in class of
+> > types (including the class of all
+> > types), or (for the second rule) an anonymous access type (for
+> > renames) or a universal type covering
+> > some type (for qualified expressions).
+> >
+>
+> I don't think that a TBH note is appropriate here (as opposed to
+> explicitly saying what is really meant), but I agree that it's a
+> judgment call.
+
+I looked at the alternatives, and they're not pretty. Trying to say this
+normatively (and still be understandable) is very difficult. Indeed, I really
+wasn't sure that I even was going to include this TBH because I didn't think it
+really makes much sense the way I described it (and I couldn't think of a better
+way to put it.
+
+If you have some description that would make sense in normative words (this
+certainly is not it), please suggest it.
+
+> > Then we need some legality rules:
+> >
+> > Legality Rules
+> >
+> > If the expected type of a conditional_expression is any type in a
+> > class of types (instead of a
+> > particular type), all dependent_expressions of the
+> > conditional_expression shall have the same type.
+> >
+>
+> Can we eliminate "if the expected type" test and replace the above
+> with something like:
+>
+> Given any two dependent_expressions of one conditional_expression,
+> either the types of the two expressions shall be the same or
+> one shall be a universal_type that covers the other.
+
+No, this is wrong. This doesn't allow the implicit conversions for class-wide
+and anonymous access types. In those cases, the types of the expressions might
+in fact be different types (remember that every anonymous access type is
+different), but that is fine so long as the expression is expected to be of a
+particular type (as opposed to one of some class of types). (I'd rather say a
+"single type", but that term is already used for something else.)
+
+I would have preferred a looser rule for this particular rule, such that the
+dependent_expressions all are expected to have the same particular expected type
+(thus allowing implicit conversions so long as they all convert to the same
+type). But that would be a really weird rule, and I can't find any cases where
+that rule would really help (neither class-wide nor anonymous access are likely
+to be involved in an "any type" scenario).
+
+> And now that we are talking about an arbitrary pair of dependent
+> expressions, we can continue with more legality checks.
+>
+> Furthermore, the two dependent_expressions shall agree with respect
+> to the properties of being statically tagged, dynamically tagged, and
+> tag indeterminant. A conditional expression is statically tagged
+> (respectively: dynamically tagged, tag indeterminant) if and only
+> if all of its dependent_expressions are.
+
+This is also wrong, in that the only interesting property is whether the
+expressions are dynamically tagged or something else. None of the legality rules
+in 3.9.2(8-9) care about tag indeterminant expressions; they're lumped in with
+statically tagged expressions.
+
+> Actually, the second sentence probably needs to be moved to
+> 3.9.2 - otherwise we are (implicitly at least) adding a
+> "notwithstanding what 3.9.2 said about these definitions"
+> here and that's undesirable.
+
+I don't see any way to reasonably say that in 3.9.2, and besides, none of the
+rules in 3.9.2 apply as the expression has no specified type. If we actually
+tried to define the type of the expression, we would have to do it in such a way
+that the taggedness is correct, in which case we'd move the second sentence here
+to the paragraph determining that (it would require lots of sentences to figure
+that out!)
+
+> > If the expected type of a conditional_expression is a specific
+> > tagged type, all of the dependent_expressions
+> > of the conditional_expression shall be dynamically tagged, or
+> > none shall be dynamically tagged; the
+> > conditional_expression is dynamically tagged if all of the
+> > dependent_expressions are dynamically tagged, and
+> > is statically tagged otherwise.
+> >
+> I think there may be a problem here with something like
+> (if cond then statically-tagged-expr else
+> tag-indeterminant-expr) which is addressed by my proposal above.
+
+No, this is find by the legality rules of 3.9.2(8-9), and we would want it to be
+treated as statically tagged for the dynamic semantics of dispatching. We
+certainly would not want to disallow mixing of tag-indeterminant and statically
+tagged cases, because most uses of tag-indeterminant items are constructor
+functions where we really want the type named in the return statement (they're
+just technically tag-indeterminant).
+
+But we probably ought to mention the case where all of the branches are
+tag-indeterminant.
+
+the conditional_expression is dynamically tagged if all of the
+dependent_expressions are dynamically tagged, is tag-indeterminate if all of the
+dependent_expressions are tag-indeterminant, and is statically tagged otherwise.
+
+> >
+> > ---
+> >
+> > So, for the moment, I'm going to allow build-in-place for conditional
+> > expressions.
+> >
+>
+> Sounds right.
+>
+> Incidentally, I agree that it seems odd that we don't have a rule
+> defining the type of a conditional expression. Even if the language
+> definition doesn't need such a rule, I think that most compiler
+> writers would find such a rule reassuring.
+>
+> If we need such a rule, perhaps something like
+> The type of a conditional expression is the unique element of the
+> set of dependent_expression types of the conditional_expression
+> which does not cover any other element of that set.
+>
+> , with an accompanying AARM argument for why this definition is
+> well-defined (at least if no legality rules have been violated).
+
+This only works because you applied a much too stringent legality rule. For
+anonymous access types, the types most likely are unrelated (and some can be
+named). If I had to do this, I would use a ladder of rules (and would try to
+include the dynamic tagging as well):
+
+The type of the conditional_expression is as followed:
+ * If the conditional_expression shall resolve to a type T, then the type of
+ the expression is T;
+ * If the expected type of the conditional_expression is any type in a class of
+ types, then the type of the conditional_expression is the type of the
+ dependent_expressions Redundant[which are all the same];
+ * If the expected type of the conditional_expression is a specific tagged type
+ T and the dependent_expressions are dynamically tagged, then the type of the
+ conditional_expression is T'Class;
+ * Otherwise, the type of the conditional_expression is the expected type T.
+
+AARM Ramification: Note that in the last case, the dependent expressions may
+have other types so long as they can be implicitly converted to T.
+
+We could drop the second sentence of the legality rules in this case. But this
+is way to many rules for something that doesn't seem to have any language need.
+If someone can find a language need, then we should do this, but otherwise I
+don't see the point.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent