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

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

```--- ai05s/ai05-0176-1.txt	2010/02/25 05:01:43	1.8
+++ ai05s/ai05-0176-1.txt	2010/04/05 23:47:36	1.9
@@ -1,4 +1,4 @@
-!standard 2.9(2/2)                                  10-02-22  AI05-0176-1/04
+!standard 2.9(2/2)                                  10-04-05  AI05-0176-1/05
!standard 3.3(19)
!standard 4.4(7)
!standard 4.5.9(0)
@@ -78,14 +78,10 @@

4.5.9 Quantified expressions

-   quantified_expression ::=
-     (quantifier defining_identifier in domain | predicate)
+   quantified_expression ::= (for quantifier loop_parameter_specification | predicate)
+   quantifier            ::= all | some
+   predicate             ::= boolean_expression

-   quantifier ::=  for all | exists
-
-   domain ::=  discrete_subtype_definition | expression
-   predicate ::= boolean_expression
-
Name Resolution Rules

The expected type of a quantified expression is any Boolean type.
@@ -2380,6 +2376,145 @@
>not expecting that solution to fly. :-)

Well, it's easy to implement (my main concern)...
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, February 25, 2010  3:53 AM
+
+> 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",
+Agreed, and the argument for Logical is important for this one.
+
+> and the type of the quantified
+> expression is the same as that of the predicate expression.
+I don't see any reason why the result type of the quantified expression should
+be the same as the type of the predicate. After all, if I write:
+
+L : Fortran.Logical;
+
+...
+
+if L = True then
+
+The type of "=" is Boolean, not logical. I see the predicate as a kind of
+"extended" equality. Why should it be different?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 25, 2010  8:10 AM
+
+Really?  I see it as an extended "and then" or "or else".
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, February 25, 2010  8:23 AM
+
+Interesting. To me, it answers the question: "Is it true that all Foos verify
+this condition?" rather than an "and then" between the evaluation of all the
+conditions.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, February 25, 2010  8:32 AM
+
+The dynamic semantics makes it clear that the evaluation is short-circuited
+(stop when counterexample is found) so this is definitely a sequence of "and
+then" between conditions.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, February 25, 2010  8:49 AM
+
+Sure - and nobody even thought of not stopping as soon as the result is known.
+But that it is implementation. From a user's point of view, I would say that
+this is a predicate. The same way you ask "is X equal to 1?" you would ask "are
+all elements of Tab equal to 1?". All comparison operators return boolean...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, February 25, 2010  9:15 AM
+
+I don't see that, because "are all elements of Tab equal to 1?" would be:
+
+    (for all I in Some_Range | Foo (I) = 1)
+
+and that will return Boolean under either rule we're arguing about, because "Foo
+(I) = 1" is Boolean.  The only issue would be if the predicate were actually of
+type Logical (or some other derived type).  For example, if you have an array A
+of Logical, and say:
+
+    (for all I in Some_Range | A (I))
+
+It seems to me the result should be Logical.
+
+You are arguing for Steve's point of view, here:
+
+> ... 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;
+
+But Steve's code could just as well be:
+
+>     Temp : Some_Derived_Boolean_Type := True;  <<<<<
+>   begin
+>     for I in Some_Range loop
+>        if not Some_Derived_Boolean_Type'(Foo (I)) then  <<<<<
+>           Temp := False;
+>           exit;
+>        end if;
+>     end loop;
+>     return Temp;
+
+(Modified lines marked <<<<<.)
+
+I find the latter more intuitive, because I always write "if not Blah"
+rather than "if Blah = False".
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, February 25, 2010  8:18 AM
+
+The update of AI-0176 seems incomplete. The version I sent a few days ago uses
+the new iterator forms, and the non-reserved keyword "for some" not "exists".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 25, 2010  12:02 PM
+
+Not sure what you are looking at. The version posted on the web (version /04)
+has all of those changes.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Thursday, February 25, 2010  7:15 PM
+
+Looking at the one on the web. The productions (under 4.5.9) are old, they
+mention "exists" and do not mention the new iterator forms (using
+loop_parameter_specification).
+
+[Editor's Note: Version /05 fixes these errors.]

****************************************************************

```

Questions? Ask the ACAA Technical Agent