CVS difference for ai05s/ai05-0176-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0176-1.txt

--- ai05s/ai05-0176-1.txt	2010/02/23 07:31:06	1.6
+++ ai05s/ai05-0176-1.txt	2010/02/25 02:10:59	1.7
@@ -1945,3 +1945,414 @@
 thinking like Steve now.)
 
 ****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, February 23, 2010  7:33 PM
+
+> Steve is right. An if-statement is a context that *provides* an
+> expected type. Kinds of expressions are defined to match certain
+> expected types, they don't have them
+
+I don't "get" this tempest in a tea pot.  Just define the doggone result type!
+
+The expected type for the predicate is "any boolean type".
+The type of a quantified_expression is Boolean.
+Word it that way: end of story, no?
+I don't get what various folks are arguing about (just wording?).
+
+There's no need to define "expected type" for quantified_expression; indeed that
+makes no sense, as Randy explains above.  Expected types go down, result types
+go up (assuming you draw trees with roots at the top and leaves at the bottom,
+like all right-thinking computer scientists do).
+
+Maybe I'm missing something...
+
+By the way, there's a bit of a notational problem here:
+
+    quantified_expression ::= (for quantifier loop_parameter_specification | predicate)
+       quantifier         ::= all | some
+       predicate          ::= boolean_expression
+
+There's an ambiguity about what "|" means (and it threw me for a loop at
+first!).
+
+"1.1.4 Method of Description and Syntax Notation" contains this kludge:
+
+12      * A vertical line separates alternative items unless it occurs
+      immediately after an opening curly bracket, in which case it stands for
+      itself:
+
+13        constraint ::= scalar_constraint | composite_constraint
+          discrete_choice_list ::= discrete_choice {| discrete_choice}
+
+Sigh.  Oh what a tangled web we weave, when first we practise to kludge.
+Apologies to Scott, whose version rhymes better, but my version is apt.
+
+I shall refrain from suggesting that "such" and "that" should be keywords,
+reserved or otherwise.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, February 24, 2010  1:17 PM
+
+> By the way, there's a bit of a notational problem here:
+>
+>    quantified_expression ::= (for quantifier
+> loop_parameter_specification | predicate)
+>       quantifier         ::= all | some
+>       predicate          ::= boolean_expression
+>
+> There's an ambiguity about what "|" means (and it threw me for a loop
+> at first!).
+
+Yes, sorry for the sloppy notation.  The vertical bar should be in quotes...
+or else we choose a different separator:  colon and right-arrow have been
+proposed:
+
+       for all X in S :  P (X)
+
+or
+
+     for all X in S => P (X)
+
+Slight preference for colon in this context, but that would conflict with the
+new iterator syntax, where we could say:
+
+    for all X : T of C : P (X)
+
+which is definitely confusing.  So right arrow may be the obvious choice.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  1:39 PM
+
+> Yes, sorry for the sloppy notation.  The vertical bar should be in
+> quotes...
+
+The first one.
+
+> or else we choose a different separator:  colon and right-arrow have
+> been proposed:
+>
+>        for all X in S :  P (X)
+>
+> or
+>
+>      for all X in S => P (X)
+>
+> Slight preference for colon in this context, but that would conflict
+> with the new iterator syntax, where we could say:
+>
+>     for all X : T of C : P (X)
+>
+> which is definitely confusing.  So right arrow may be the obvious
+> choice.
+
+Well, I hate for our inability to say "|" in our meta-language drive the actual
+syntax.
+
+Anyway, I agree ":" is confusing.  I could live with either "=>" or "|".
+
+Maybe we should change "1.1.4 Method of Description and Syntax Notation"
+to say that "|" (with the quotes) stands for a vertical line, and change the
+syntax for discrete_choice_list, discriminant_association,
+component_choice_list, and exception_handler to quote the thing?
+
+(If I ran the circus, all literal terminals would be quoted.)
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Wednesday, February 24, 2010  1:55 PM
+
+> Yes, sorry for the sloppy notation.  The vertical bar should be in
+> quotes...
+> or else we choose a different separator:  colon and right-arrow have
+> been proposed:
+
+Just because there's a notational issue with the syntax doesn't mean we should
+change to a different separator.  Let's please stick with the vertical bar and
+resolve the syntax notation issue somehow.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 24, 2010  2:04 PM
+
+I agree.  "|" seems preferable to other separators.
+
+In other places where we use "|" in the syntax (e.g. 4.3.1 record aggregates),
+the distinction seems to be merely one of the font (which is admittedly pretty
+subtle).
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, February 24, 2010  2:05 PM
+
+> Just because there's a notational issue with the syntax doesn't mean
+> we should change to a different separator.  Let's please stick with
+> the vertical bar and resolve the syntax notation issue somehow.
+
+I wasn't suggesting the other possible separators just because of the notational
+issue. I've heard objections (on aesthetic grounds) about the use of the
+vertical bar here (from John in particular), and other had suggested  => as more
+meaningful.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 24, 2010  7:59 PM
+
+> I agree.  "|" seems preferable to other separators.
+>
+> In other places where we use "|" in the syntax (e.g. 4.3.1 record
+> aggregates), the distinction seems to be merely one of the font (which
+> is admittedly pretty subtle).
+
+All such cases follow "{", and the wording that Bob pointed out covers that
+explicitly. This is the first time | is used to separate something other than a
+list, so now we have a problem. No solution comes to mind. (One also wonders
+about the inconsistency of using a list separator in a non-list context. I'd
+solve the problem by not bothering with this feature, but I'm not expecting that
+solution to fly. :-)
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, February 24, 2010  1:26 PM
+
+> I don't get what various folks are arguing about (just wording?).
+
+Pretty much.
+
+There is a more-than-just-wording question about a corner case which nobody
+seems to feel strongly about, but which needs to be resolved one way or the
+other:
+
+    If the predicate expression is of a derived boolean type, is
+    the type of the quantified expression Standard.Boolean or is
+    it the derived boolean type?
+
+I argued that if we choose Standard.Boolean, then a quantified expression is a
+lot like a qualified expression in the sense that its type can be determined
+independently of its context.
+
+This suggested to me that we should therefore use the wording for qualified
+expressions as a model.
+
+Unfortunately, this introduced confusion because, as Randy pointed out, the
+wording for qualified expressions isn't really right. It hasn't changed for many
+years and there have been no complaints about it, but doesn't explicitly define
+the type of a qualified expression. It does define the nominal subtype, but
+Randy says that "4.7(3.1/3) has nothing to do with resolution,".
+
+So something like
+   The type of a quantified_expression is the predefined
+   type Boolean.
+is probably needed.
+
+If we go the other way on the derived-boolean-type corner-case question, then of
+course things are different.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, February 24, 2010  1:42 PM
+
+> So something like
+>  The type of a quantified_expression is the predefined  type Boolean.
+> is probably needed.
+
+That's certainly the simplest. I see zero advantage in saying "any boolean
+type" here (or elsewhere for that matter...).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  1:44 PM
+
+>     If the predicate expression is of a derived boolean type, is
+>     the type of the quantified expression Standard.Boolean or is
+>     it the derived boolean type?
+
+I see.  The correct answer is "Who cares?", but I agree we need to decide one
+way or 'tother.
+
+...
+> So something like
+>    The type of a quantified_expression is the predefined
+>    type Boolean.
+> is probably needed.
+
+OK with me.  It does mean that Interfaces.Fortran.Logical gets implicitly
+converted to Boolean, which involves a change of representation.  Problem?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 24, 2010  1:57 PM
+
+I think I disagree with saying it is the predefined type Boolean, on language
+consistency grounds. Standard.Boolean appears essentially nowhere in the name
+resolutions rules, so why introduce it here?
+
+Since conditions are allowed to be of any boolean type, then I would say the
+expected type for the predicate expression is "any boolean type", and the type
+of the quantified expression is the same as that of the predicate expression.
+In fact, if you define "predicate" as:
+
+   predicate ::= condition
+
+then I think much of this happens for free, since "condition" is already defined
+in RM 5.3 to have an expected type of "any boolean type."
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  2:15 PM
+
+> I think I disagree with saying it is the predefined type Boolean, on
+> language consistency grounds.
+> Standard.Boolean appears essentially nowhere in the name resolutions
+> rules, so why introduce it here?
+
+I think I agree with Tucker here.
+
+> Since conditions are allowed to be of any boolean type, then I would
+> say the expected type for the predicate expression is "any boolean
+> type", ...
+
+Yes, definitely -- that's the way everything else works, so should be easiest to
+implement.  That's what I suggested before.
+
+>...and the type of the quantified
+> expression is the same as that of the predicate  expression.
+
+Yes, I've changed my mind, and now agree it should not be hardwired to Boolean.
+I actually think this is easier to implement, because you don't have to
+implicitly convert from Derived_Boolean to Boolean (which could require a change
+of representation).
+
+>...In fact, if you define "predicate" as:
+>
+>    predicate ::= condition
+>
+> then I think much of this happens for free, since "condition" is
+> already defined in RM 5.3 to have an expected type of "any boolean
+> type."
+
+Good idea.  This covers the expected type of the predicate.
+We still need to say that the type of the quant_exp is that of the predicate.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  2:18 PM
+
+> That's certainly the simplest.  I see zero advantage in saying "any
+> boolean type"  here (or elsewhere for that matter...).
+
+Perhaps, but we already do so elsewhere, so it's simplest to do likewise here.
+
+Anyway, it's kind of convenient to be able to use if statements on type
+Interfaces.Fortran.Logical.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 24, 2010  2:55 PM
+
+Is this Bob Duff I or Bob Duff II?
+I thought you just sent out a note agreeing the predicate should be expected to be of any boolean type, and the quantified expression should be that same type.
+
+Implicit converting to Standard.Boolean
+seems of little value, and if someone has gone to the effort of using a
+non-standard boolean type, they would presumably be annoyed that all of the
+logical operations preserve their non-standard boolean type *except* quantified
+expressions.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 24, 2010  3:05 PM
+
+Some of Bob's messages got delivered out of order because they were briefly
+delayed in the spam filter. That might account for the confusion.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Wednesday, February 24, 2010  3:14 PM
+
+> Implicit converting to Standard.Boolean seems of little value, and if someone
+> has gone to the effort of using a non-standard boolean type, they would
+> presumably be annoyed that all of the logical operations preserve their
+> non-standard boolean type *except* quantified expressions.
+
+the argument about Fortran.Logical seems compelling, so I agree that these
+should be treated like other conditions. "Any boolean type"is fine.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, February 24, 2010  3:29 PM
+
+> I see.  The correct answer is "Who cares?", but I agree we need to
+> decide one way or 'tother.
+
+Agreed.
+
+>> So something like
+>>    The type of a quantified_expression is the predefined
+>>    type Boolean.
+>> is probably needed.
+>
+> OK with me.  It does mean that Interfaces.Fortran.Logical gets
+> implicitly converted to Boolean, which involves a change of
+> representation.  Problem?
+
+I don't see it as a problem, although it sounds like it doesn't matter whether
+it is a problem or not because folks seem to be leaning towards the "use the
+type of the predicate" approach (which is fine with me).
+
+One could even argue that there isn't any change of representation (or at least
+it is well camouflaged) if you choose to think of a quantified expression as I
+described it in an earlier message:
+
+> ... I have no problem thinking of
+>
+>     (for all I in Some_Range | Some_Derived_Boolean_Type'(Foo (I)))
+>
+> as being equivalent to a call to a function with body
+>
+>     Temp : Standard.Boolean := True;
+>   begin
+>     for I in Some_Range loop
+>        if Some_Derived_Boolean_Type'(Foo (I)) = False then
+>           Temp := False;
+>           exit;
+>        end if;
+>     end loop;
+>     return Temp;
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  3:35 PM
+
+> Is this Bob Duff I or Bob Duff II?
+> I thought you just sent out a note agreeing the predicate should be
+> expected to be of any boolean type, and the quantified expression
+> should be that same type.
+
+I think you read my e-mails in the opposite order I sent them.
+
+I changed my mind.  My current opinion agrees with yours.
+Reasons:  Easier to implement.  Better for the user of derived types (not many
+of those, but we do have Logical).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent