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

--- ai05s/ai05-0147-1.txt	2010/02/02 04:49:31	1.10
+++ ai05s/ai05-0147-1.txt	2010/02/04 07:11:43	1.11
@@ -118,7 +118,7 @@
 
 condition ::= *boolean_*expression
 
-Whereever the Syntax Rules allow an expression, a conditional_expression may be
+Wherever the Syntax Rules allow an expression, a conditional_expression may be
 used in place of the expression, so long as it is immediately surrounded by
 parentheses.
 
@@ -7561,7 +7561,8 @@
 >      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 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:
 >
@@ -7875,6 +7876,18 @@
 
 ****************************************************************
 
+From: Robert Dewar
+Sent: Monday, February  1, 2010  9:42 PM
+
+> Didn't we explicitly decide against
+> this because of interactions with case expressions (and we wanted the
+> same parenthesizing rules for conditional expressions as for case
+> expressions)?
+
+I prefer to keep the parens after =>
+
+****************************************************************
+
 From: Bob Duff
 Sent: Monday, February  1, 2010  3:31 PM
 
@@ -8074,5 +8087,141 @@
 ...
 
 or something like that.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, February  2, 2010  3:05 PM
+
+...
+> I wanted to be crystal-clear about the equivalence, and the defaulted "else"
+> is not crystal-clear to me. Indeed, I have to look it up each time to
+> figure out what it is.
+
+I find it perfectly intuitive.  Think of this way:
+"Assert(if X then Y);" means that if X is False, we're not asserting anything,
+which means "Assert(True)".
+
+> Perhaps the thing to do is here to give both by adding:
+>
+> or even more simply
+>     Precondition => (if Param_1 >= 0 then Param_2 /= "")
+>
+> to the AI.
+
+Sounds good to me.
+
+...
+> Oh, sorry. I should have written:
+>
+>           Working_Object : Some_Type renames
+>              Some_Type'(if Some_Func(A) then A else B);
+>
+> because you can make any expression a name by qualifying it (AI05-0003-1).
+
+Interesting; I hadn't quite realized the ramifications of that.
+
+> And, as Tucker pointed out, you can do that in Ada 95-speak, without
+> AI05-0003-1, too:
+>           Working_Object : Some_Type renames
+>              Some_Type(Some_Type'(if Some_Func(A) then A else B));
+
+Bleah.
+
+> But there is a weirdness here, because the name represents a constant
+> view (at least according to AI05-0003-1). So it isn't a 100%
+> replacement for the renaming.
+>
+> One wonders if we want a rule to disallow this case (is it more
+> confusing than helpful??). I think it would have to be a specific rule.
+
+I don't see any reason to outlaw it.  It might surprise some folks when they see
+it for the first time, but it's obvious what it means.
+
+I don't see any big implementation burden.  (If I'm wrong about that, then I'll
+change my mind.)
+
+...
+> I think this is a special case. The grammar in the standard is
+> seriously ambiguous and since a reasonably easy solution is known and
+> available, I think we should give it and explain why they would like
+> to use it. That's especially true because my professional opinion was
+> that it couldn't be done (I thought that inherent ambiguity,
+> especially for "name", would have made it impossible). This is one
+> case where I was happy to be proved wrong, and I don't want to lose
+> that information as other implementers may have similar problems.
+
+I agree we should include Steve's grammar.  I just don't see any need to push
+it.  Lead the horses to water, and let them drink if they like.
+
+>...(And not everyone one reads the AIs, or even knows what they are.)
+
+Surely implementers read AIs!
+
+> You could argue that there are existing cases like that in the Ada
+> grammar; I agree with that but think they too ought to have AARM notes
+> if the published grammar is problematic. Type_conversion comes to mind
+> (this has to be treated as a form of name, especially as it is allowed
+> to be *used* as a name). There are only a few such places in the
+> standard; it's annoying that new Ada implementers are supposed to
+> figure out these problems and solutions on their own.
+
+Agreed.
+
+> Anyway, there may be a better way to put this, but clearly every
+> implementer will need a solution to avoid the ambiguity (unless they
+> are using an ambiguous grammar parser, but that seems unlikely). So I
+> think we ought to help. Your elimination of any grammar at all will
+> make it even harder for readers to make sense of this. Maybe something like:
+>
+> AARM Implementation Note: Directly adding conditional_expression in
+> place of expression causes a very ambiguous grammar. Instead, it is
+> possible to modify the grammar for all of the above productions to reflect this rule.
+> ...
+>
+> or something like that.
+
+I agree.  I proposed something like that in my other e-mail (the one titled
+"[ARG] ai05-0147-1: New proposal for syntax rules". See "... (put Steve's work
+here)".
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, February  2, 2010  4:01 AM
+
+> Didn't we explicitly decide against
+> this because of interactions with case
+> expressions (and we wanted the same parenthesizing
+> rules for conditional expressions as
+> for case expressions)?
+
+We did indeed and I object quite strongly to deviating from that decision.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February  2, 2010  7:24 AM
+
+Sorry, I had forgotten about the "case expression"
+issue after "=>".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February  2, 2010  9:41 AM
+
+> We did indeed and I object quite strongly to deviating from that decision.
+
+For me, the rule that you can leave out parens if there are parens already
+around is simple to state and adequate.
+
+****************************************************************
+
+From: John Barnes
+Sent: Wednesday, February  3, 2010  2:11 AM
+
+Indeed. Even an ordinary application programmer will understand it. Please
+let's stick with that.
 
 ****************************************************************