CVS difference for ai05s/ai05-0147-1.txt
--- ai05s/ai05-0147-1.txt 2011/02/16 06:15:23 1.23
+++ ai05s/ai05-0147-1.txt 2012/01/22 06:24:00 1.24
@@ -96,9 +96,9 @@
(if B then E1 else E2)
-Note that there is no end if. However, a conditional
-expression is always surrounded by parentheses. In most
-contexts where there are already parentheses, then only one
+Note that there is no end if. However, a conditional
+expression is always surrounded by parentheses. In most
+contexts where there are already parentheses, then only one
pair is needed, thus a procedure call might be
P(if B then E1 else E2);
@@ -107,7 +107,7 @@
P(if B1 then E1 elsif B2 then E2 else E3);
-If the type of the expression is boolean then an else part of
+If the type of the expression is boolean then an else part of
the form else True can be omitted.
!wording
@@ -414,7 +414,7 @@
unique type can be determined for the conditional expression, so it is illegal,
even though both of the expressions would be OK if used directly as conditions
(the condition of an if_statement requires "any boolean type").
-
+
Note that if a type is identified by context, only convertability is required
of the *dependent_*expressions. This allows implicit conversions (including to
class-wide and access types) to work properly. If the types of the
@@ -8792,6 +8792,1005 @@
Sent: Tuesday, July 27, 2010 7:38 AM
Makes sense to me.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, December 29, 2011 3:25 PM
+
+For a conditional expression, 4.5.7 (20/3) says that when there is no else
+clause, the value of the if expression is True.
+
+I find this makes sense for things like Preconditions and Assertions, where you
+want to basically assert that something is True, but I find it can be confusing
+for other uses of conditional expressions.
+
+Consider;
+
+ Age : constant Natural := 12;
+ Alcohol_Level : constant Float := 0.009;
+
+If I want to write some Boolean expression for an assignment statement, one
+might write;
+
+ Allowed_To_Drive : constant Boolean :=
+ Age >= 21 and then Alcohol_Level < 0.008; -- Evaluates to False
+
+One might want to write/rewrite this as a conditional expression.
+
+ Allowed_To_Drive : constant Boolean :=
+ (if Age >= 21 and then Alcohol_Level < 0.008 then True);
+ -- Evaluates to True
+
+One might be very surprised to find that everyone is allowed to drive, there are
+no restrictions.
+
+This seems like a source of bugs. Are we OK with this, or would it make sense to
+only allow the implicit else for preconditions/postconditions/asserts?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, December 29, 2011 3:37 PM
+
+> This seems like a source of bugs. Are we OK with this, or would it
+> make sense to only allow the implicit else for
+> preconditions/postconditions/asserts?
+
+I'm OK with this.
+
+I wouldn't mind implementing something in GNAT, perhaps a restriction or switch
+that gives a warning in problematic cases. Other compilers are free to do
+likewise. I don't think we want a language rule.
+
+I'm not sure what the "problematic cases" are. You characterize it as "implicit
+else outside of an assertion". But maybe it should be "then True" -- if you say
+"then True" and leave the "else" out, that's a problem, even in an assertion.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 29, 2011 3:51 PM
+
+> For a conditional expression, 4.5.7 (20/3) says that when there is no
+> else clause, the value of the if expression is True.
+...
+> This seems like a source of bugs. Are we OK with this, or would it
+> make sense to only allow the implicit else for
+> preconditions/postconditions/asserts?
+
+I'd rather drop the idea altogether. It's a source of bugs even for asserts, and
+I really don't like the idea of context-sensitive legality rules for
+expressions.
+
+Ada is not, in general, about cute shortcuts, and this feels precisely like that
+to me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 29, 2011 4:00 PM
+
+...
+> I'm not sure what the "problematic cases" are. You characterize it as
+> "implicit else outside of an assertion".
+> But maybe it should be "then True" -- if you say "then True"
+> and leave the "else" out, that's a problem, even in an assertion.
+
+There clearly are problematic cases beyond "then True". What if the conditional
+expression in Brad's example had been:
+
+ Allowed_To_Drive : constant Boolean :=
+ (if Age >= 21 then Alcohol_Level < 0.008);
+
+We're now enforcing DUI only on drivers over 21, and allowing anyone under 21 to
+drive without regard to their alcohol. Drunk 12 year-olds are OK on the highway!
+Cool!
+
+Thus, I'd argue that all cases (or at least almost all) are problematic.
+Moreover, you have to go look up in the RM what the result is (it's not in the
+code, and it's hard to remember whether it is True or False). It's a feature
+that I'd use rarely, if at all -- which makes it even harder to deal with when
+it is used.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, December 29, 2011 4:04 PM
+
+> I wouldn't mind implementing something in GNAT, perhaps a restriction
+> or switch that gives a warning in problematic cases.
+> Other compilers are free to do likewise. I don't think we want a
+> language rule.
+>
+> I'm not sure what the "problematic cases" are. You characterize it as
+> "implicit else outside of an assertion". But maybe it should be "then
+> True" -- if you say "then True" and leave the "else" out, that's a
+> problem, even in an assertion.
+
+You're right, the question should be rephrased to;
+
+Should an implicit else True be allowed if all the dependent expressions of an
+if expression evaluate to True?
+
+It seems likely that this would indicate a bug. Forcing the programmer to
+explicitly state the else True for this case, seems reasonable to me, and better
+than relying on compiler vendors to flag this as a warning, or relying on
+programmers to notice the warning.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Thursday, December 29, 2011 4:13 PM
+
+I should probably have said;
+
+Should an implicit else True be allowed if all the dependent expressions of an
+if expression {statically} evaluate to True?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 29, 2011 4:20 PM
+
+>> This seems like a source of bugs. Are we OK with this, or would it
+>> make sense to only allow the implicit else for
+>> preconditions/postconditions/asserts?
+>
+> I'm OK with this.
+
+I don't like limiting the implicit "else True" to assertion expressions. There
+are procedures named "Assert" and other places where an "implies" construct is
+useful.
+
+> I wouldn't mind implementing something in GNAT, perhaps a restriction
+> or switch that gives a warning in problematic cases.
+> Other compilers are free to do likewise. I don't think we want a
+> language rule.
+>
+> I'm not sure what the "problematic cases" are. You characterize it as
+> "implicit else outside of an assertion". But maybe it should be "then
+> True" -- if you say "then True" and leave the "else" out, that's a
+> problem, even in an assertion.
+
+I would agree that "(if blah then True)" deserves a warning, since it always
+evaluates to True. I might also think that "(if blah then False)" deserves a
+warning. Both of them indicate that the programmer doesn't get the point of the
+construct, and is probably confused.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 29, 2011 4:42 PM
+
+...
+> I would agree that "(if blah then True)" deserves a warning, since it
+> always evaluates to True. I might also think that "(if blah then
+> False)" deserves a warning. Both of them indicate that the programmer
+> doesn't get the point of the construct, and is probably confused.
+
+I would argue that any use of implicit "else True" should get a low-priority
+warning (or perhaps an "information", if your implementation has such a thing).
+A lot of the time, it will be omitted by accident, and even if not, the
+"information" will serve as a reminder of what it means.
+
+My style guide will strongly discourage using implicit "else True", so that
+makes it even more important to have a reminder what it means when it is
+encountered in other people's code.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, December 29, 2011 4:46 PM
+
+> I don't like limiting the implicit "else True" to assertion
+> expressions. There are procedures named "Assert" and other places
+> where an "implies" construct is useful.
+
+Long time ago, we talked about adding an "implies" operator.
+I was all for it, but some folks found it confusing.
+I gave in, because of the implicit "else True", which I find entirely natural.
+
+To me, "(if X then Y)" is just as understandable as "(X implies Y)", and to some
+folks, more understandable. So if folks are now wanting to forbid the implicit
+"else True", I will insist that we need an "implies" operator.
+
+In other words, I agree with Tucker.
+
+I really think "Check(if X /= null then Is_Good(X.all));"
+is better than "Check(if X /= null then Is_Good(X.all) else True);".
+
+> I would agree that "(if blah then True)" deserves a warning, since it
+> always evaluates to True. I might also think that "(if blah then
+> False)" deserves a warning. Both of them indicate that the programmer
+> doesn't get the point of the construct, and is probably confused.
+
+Sure, all sorts of things deserve a warning. I think it's a fool's errand to
+try to codify such rules right now for Ada 2012. How about "X := X + 0;"?
+
+There are many ways to write confusing code in Ada. The solution
+is: Don't do that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, December 29, 2011 5:05 PM
+
+> Long time ago, we talked about adding an "implies" operator.
+> I was all for it, but some folks found it confusing.
+> I gave in, because of the implicit "else True", which I find entirely
+> natural.
+>
+> To me, "(if X then Y)" is just as understandable as "(X implies Y)",
+> and to some folks, more understandable.
+
+I find "(if X then Y)" more understandable than "implies"
+when writing assertions.
+
+> So if folks are now wanting to forbid the implicit "else True", I will
+> insist that we need an "implies" operator.
+
+It is too late for this sort of a change in my view, and if it weren't I would
+certainly agree with Bob that we need something like "implies." We have several
+places in our code where you will find:
+
+ pragma Assert(X <= Y); -- i.e. X implies Y
+
+As indicated above, I think "(if X then Y)"
+is even better than "implies" when used in an assertion, and sure beats the
+pants off of "X <= Y".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, December 29, 2011 5:49 PM
+
+...
+> To me, "(if X then Y)" is just as understandable as "(X
+> implies Y)", and to some folks, more understandable.
+> So if folks are now wanting to forbid the implicit "else
+> True", I will insist that we need an "implies" operator.
+>
+> In other words, I agree with Tucker.
+>
+> I really think "Check(if X /= null then Is_Good(X.all));"
+> is better than "Check(if X /= null then Is_Good(X.all) else True);".
+
+It's surely easier to read the first, but if you want to actually know what
+it means, you better write the second.
+
+We had this discussion in the past, and it doesn't pay to rehash most of it,
+but since you restarted it:
+
+I don't want anyone (you, Tucker, or anyone else) writing expressions
+involving implies (or any other boolean operator that requires an advanced
+degree in boolean logic to understand) in Ada in *any* form. Both of the
+above are if-expressions to me, and as an if expression, the second one is
+many times clearer (there is no guessing about what the else part is).
+
+Moreover, I think that Check (X /= null and then Is_Good(X.all)); is better
+than both of the above (no silly else part - implied or explicit). That
+won't always be true (depends on what the initial expression is, and whether
+there is a significant content to the else part) -- but the above is a
+standard Ada idiom that I've been writing since 1980, and I'd expect it is
+highly familiar to every Ada programmer.
+
+Finally, I'm a literalist. I don't like leaving out optional parts: I almost
+always write the mode "in" on parameters; I usually explicitly initialize
+access values (only leaving it out in true "don't care" circumstances, which
+are fairly rare); I rarely use "use" clauses, preferring to write the fully
+expanded name, even "Ada.Strings.Unbounded.To_Unbounded_String"; I'll even
+write prefix calls of operators rather than "use"ing them (Host."=" (A, B))
+if there are only a few occurrences in a scope. Surely this is going to be
+another option that I would never consider using and having it just
+complicates the language for little value.
+
+Tucker writes:
+> It is too late for this sort of a change in my view, ...
+
+That's a silly opinion; this is a single line change in the Standard, and I
+believe it is mostly a deletion. We're almost certainly going to make much
+larger changes than that during the February meeting. So it's not too late,
+especially to eliminate something that will be a common source of bugs in
+practice.
+
+But I would agree on one point: if we are going to make a change of anything
+significant, we definitely need a consensus to make it. And it's clear that
+we don't have it on this point. In which case, things will stay as they are.
+Hopefully compilers will give us useful warnings on this. Something like:
+
+22: Check(if X /= null then Is_Good(X.all));
+-------------------------------------------^
+*Information* Assumed "else True", are you really sure that you want to
+confuse 50% of Ada programmers?? :-)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, December 30, 2011 1:27 AM
+
+The justification for omitting the "else" part was to reflect the "implies"
+relationship (we had long discussions about this). Has anything changed?
+
+...
+> My style guide will strongly discourage using implicit "else True", so
+> that makes it even more important to have a reminder what it means
+> when it is encountered in other people's code.
+
+Added to the 2012-todo list of AdaControl, thanks ;-)
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, December 30, 2011 2:05 AM
+
+> The justification for omitting the "else" part was to reflect the
+> "implies" relationship (we had long discussions about this). Has
+> anything changed?
+
+Nothing has changed, nor does it appear likely that anything will change.
+
+I don't believe we had discussed much about how the implicit else true works
+with conditional expressions that are not associated with assertions and
+preconditions, however. In particular, I noticed that the default for a Boolean
+Expression is assumed to be False, while the default for a Boolean
+If_Expressions is assumed to be True, and was bothered by the thought this would
+likely be a source of confusion and bugs.
+
+I'm still find this bothersome, but probably a compiler warning is the best we
+can do, given that we do want to keep the implicit Else True in the syntax as it
+is currently.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 3:19 AM
+
+I would find it totally unacceptable to have different syntax and semantics in
+preconditions, postconditions, and assertions. I would find that confusing and
+unjustified.
+
+If you have
+
+ pragma Assert (bla)
+
+then you really want to KNOW that you can convert this to
+
+ if not bla then
+ Special_Error_Log (...);
+ end if;
+
+and not find that the syntax and semantics of bla has changed.
+
+So for me, it is a given that either we allow the implicit else true both places
+or neither.
+
+I can't get too worried about the cases where the result evaluates at compile
+time to True or False. Any reasonable compiler will warn in such cases anyway.
+
+So I am happy with the status quo here, but don't mind too much if the implicit
+"else true" is removed.
+
+But bottom line for me is that the burden is heavy for changes at this stage,
+users of the language will have had a couple of years using a compiler where the
+implicit else true is implemented, and I don't see the argument for change.
+
+Basically I think we only make significant changes at this stage if we find
+significant new arguments or difficulties we had not thought of before. Then of
+course we do consider changes, even at the last minute, and it is irrelevant
+that there is an implementation out there implenting the (now realized to be)
+wrong semantics/syntax.
+
+Here we have nothing new at all, no new insights, no new observations, no new
+problems, etc. So why make the modification. As someone else said "What has
+changed?" Answer: nothing has changed, and the decision process that lead to
+this decision (driven by the importance of a nice notation for implies) has not
+changed.
+
+All we have is a few examples where the use of the implicit ELSE TRUE is not a
+good idea. So what? There are many ways to misuse the language!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 6:38 AM
+
+> I would argue that any use of implicit "else True" should get a
+> low-priority warning (or perhaps an "information", if your
+> implementation has such a thing). A lot of the time, it will be
+> omitted by accident, and even if not, the "information" will serve as a
+> reminder of what it means.
+
+I disagree, the point here is that most of us agreed that some convenient
+notation for the IMPLIES operator is required, and settled on this. It would be
+irritating to have junk false positive warnings for reasonable uses of Implies.
+
+> My style guide will strongly discourage using implicit "else True", so
+> that makes it even more important to have a reminder what it means
+> when it is encountered in other people's code.
+
+Your style guide will do a disservice to people using contracts for programming
+extensively, where the implies operator is important.
+
+But fine, you are free to do whatever you like if it does not involve changing
+the standard.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 6:47 AM
+
+> ...
+>> To me, "(if X then Y)" is just as understandable as "(X implies Y)",
+>> and to some folks, more understandable.
+>> So if folks are now wanting to forbid the implicit "else True", I
+>> will insist that we need an "implies" operator.
+>>
+>> In other words, I agree with Tucker.
+>>
+>> I really think "Check(if X /= null then Is_Good(X.all));"
+>> is better than "Check(if X /= null then Is_Good(X.all) else True);".
+>
+> It's surely easier to read the first, but if you want to actually know
+> what it means, you better write the second.
+
+I strongly disagree with Randy here, the second form is confusing compared to
+the first.
+
+> I don't want anyone (you, Tucker, or anyone else) writing expressions
+> involving implies (or any other boolean operator that requires an
+> advanced degree in boolean logic to understand) in Ada in *any* form.
+> Both of the above are if-expressions to me, and as an if expression,
+> the second one is many times clearer (there is no guessing about what the else part is).
+
+No advanced degree is needed, you are rehashing wrong arguments you made before,
+which as I remember convinced no one.
+
+> Finally, I'm a literalist. I don't like leaving out optional parts: I
+> almost always write the mode "in" on parameters; I usually explicitly
+> initialize access values (only leaving it out in true "don't care"
+> circumstances, which are fairly rare); I rarely use "use" clauses,
+> preferring to write the fully expanded name, even
+> "Ada.Strings.Unbounded.To_Unbounded_String"; I'll even write prefix
+> calls of operators rather than "use"ing them (Host."=" (A, B)) if
+> there are only a few occurrences in a scope. Surely this is going to
+> be another option that I would never consider using and having it just complicates the language for little value.
+
+Fine literalize away and make your code unreadable, but do not insist that
+others follow this course by distorting the language!
+
+> Tucker writes:
+>> It is too late for this sort of a change in my view, ...
+>
+> That's a silly opinion; this is a single line change in the Standard,
+> and I believe it is mostly a deletion. We're almost certainly going to
+> make much larger changes than that during the February meeting. So
+> it's not too late, especially to eliminate something that will be a
+> common source of bugs in practice.
+
+And it would be a bad change, and we have at the very least Robert, Tuck, and
+Bob strongly opposed. By "this sort of change" tucker means things that are
+controversial, which this most certainly is.
+
+> But I would agree on one point: if we are going to make a change of
+> anything significant, we definitely need a consensus to make it. And
+> it's clear that we don't have it on this point. In which case, things will stay as they are.
+> Hopefully compilers will give us useful warnings on this. Something like:
+>
+> 22: Check(if X /= null then Is_Good(X.all));
+> -------------------------------------------^
+> *Information* Assumed "else True", are you really sure that you want
+> to confuse 50% of Ada programmers?? :-)
+
+Certainly GNAT won't give any such warning in a case like this, it would
+generate lots of junk, so your hopefully will remain a vain wish. You are free
+to put anything you like into your compiler, but I think the claim that this
+will confuse 50% of Ada programmers is nonsense. In a case like
+
+ Check (if bla then junk)
+
+I think almost all people would understand this to mean
+
+ if bla then
+ check (junk)
+ end if;
+
+Note that even randy has not got to the point where he would want the compiler
+to flag the above with
+
+ *Information* assumed "else null", are you really sure ...
+
+To me these two contructs are entirely parallel
+
+Of course if bla is always true or always false, then I would expect a warning
+in both cases.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 30, 2011 8:17 AM
+
+> > I really think "Check(if X /= null then Is_Good(X.all));"
+> > is better than "Check(if X /= null then Is_Good(X.all) else True);".
+
+> It's surely easier to read the first, but if you want to actually know
+> what it means, you better write the second.
+>
+> We had this discussion in the past, and it doesn't pay to rehash most
+> of it, but since you restarted it:
+
+Brad restarted it, not me. Yes, we've discussed these issues in the past, and
+I'm happy with the outcome -- implicit else can be used as a clean, readable way
+to write the "implies" operator.
+
+> Moreover, I think that Check (X /= null and then Is_Good(X.all)); is
+> better
+
+Except that it doesn't mean the same thing. When X = null, my two 'if'
+expressions above yield True, whereas this 'and then' yields False. I'm not
+sure what this proves with regard to what is or is not confusing. ;-)
+
+> than both of the above (no silly else part - implied or explicit).
+> That won't always be true (depends on what the initial expression is,
+> and whether there is a significant content to the else part) -- but
+> the above is a standard Ada idiom that I've been writing since 1980,
+> and I'd expect it is highly familiar to every Ada programmer.
+>
+> Finally, I'm a literalist.
+
+I have no objection to anyone being a literalist, but I object to people trying
+to impose their own personal style on everyone -- unless, of course, that style
+is broadly agreed upon.
+
+>...I don't like leaving out optional parts: I almost always write the
+>mode "in" on parameters; I usually explicitly initialize access values
+>(only leaving it out in true "don't care" circumstances, which are
+>fairly rare); I rarely use "use" clauses, preferring to write the fully
+>expanded name, even "Ada.Strings.Unbounded.To_Unbounded_String"; I'll
+>even write prefix calls of operators rather than "use"ing them
+>(Host."=" (A, B)) if there are only a few occurrences in a scope.
+
+I'm not a literalist -- I agree with 1.5 out of the above 4 examples of
+literalism. But I won't try to impose my view on you -- feel free to write
+abominations like Host."=". ;-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 30, 2011 8:19 AM
+
+>...We're almost certainly going to make much larger changes than that
+>during the February meeting.
+
+I hope not.
+
+At some point, we have to put down our pencils and turn in our work, lest we
+keep fiddling with this thing forever!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 30, 2011 1:51 PM
+
+WG 9 explicitly asked us to continue "fiddling with this thing" through the
+February meeting (and no further). There was a concern that it was not yet
+mature enough to standardize.
+
+One presumes that we will (and already have in a few cases) find issues that
+need addressing because they weren't considered enough the first time. And we're
+not going to come up with the solutions for those things here.
+
+I do agree that this issue isn't one of those, though. This one will get filed
+in the AC bin (hopefully never to see the light of day).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 30, 2011 8:27 AM
+
+> Certainly GNAT won't give any such warning in a case like this, it
+> would generate lots of junk, so your hopefully will remain a vain wish.
+
+Well, if customers ask for it, I would have no objection to implementing such
+warnings (turned off by default). We already have lots of warnings (some
+implemented in the compiler, some in gnatcheck) that we do not recommend people
+use, simply because some customers wanted them (or thought they did).
+
+I find that a Restriction is an excellent way to defuse arguments of the form
+"Feature X is evil [in my situation]", "No, feature X is good [in MY
+situation]", ...(repeat).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 8:26 PM
+
+> Well, if customers ask for it, I would have no objection to
+> implementing such warnings (turned off by default).
+
+Perhaps, or perhaps this kind of thing is better as a gnatcheck style rule (as
+suggested by JPR for his tool). I think that warning on all uses of a language
+feature is wrong, because then you are talking about a style rule, rather than
+warnings.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, December 30, 2011 8:21 AM
+
+>... In particular, I noticed that the default for a Boolean Expression
+>is assumed to be False, while the default for a Boolean If_Expressions
+>is assumed to be True, and was bothered by the thought this would
+>likely be a source of confusion and bugs.
+
+I don't know what you mean by "default for a Boolean Expression".
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, December 30, 2011 12:41 PM
+
+>> ... In particular, I noticed that the default for a Boolean
+>> Expression is assumed to be False, while the default for a Boolean
+>> If_Expressions is assumed to be True, and was bothered by the thought
+>> this would likely be a source of confusion and bugs.
+> I don't know what you mean by "default for a Boolean Expression".
+
+I'm thinking in an abstract sense, more in terms of boolean logic, than Ada
+semantics But If I write;
+
+if (A) then ...
+where A is some Boolean expression,
+
+You can think of this logically as;
+if the value of expression A is true, the value of the condition is True, else
+it is False. (i.e. False by default)
+
+i.e. This is equivalent to;
+
+if (if A then True else False) then
+
+If I instead initially wrote;
+
+if (if A then True) then ...
+
+or even
+
+if (if A then A) then ...
+
+Which at first glance might appear to look equivalent to if (A), this really is
+equivalent to if (if A then True else True) then ... i.e., True by default.
+
+I'll bet if the following question was asked on an Ada 101 course, a lot of
+people would get this wrong.
+
+What is the output for the following?
+
+A : Boolean := False;
+if (if A then A) then
+ Put_Line ("Foo");
+else
+ Put_Line ("Bar");
+end if;
+
+I'm don't believe this is setting a new precedent however.
+I'm sure there are plenty of other ways to write confusing code in Ada.
+
+I'm more concerned about cases where people think they are writing correct,
+understandable code, when the actual behavior does not match the expectations of
+the programmer. Hopefully this can be covered by issuing compiler warnings for
+suspicious usage for conditional expressions.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 30, 2011 2:46 PM
+
+...
+> > Hopefully compilers will give us useful warnings on this. Something like:
+> >
+> > 22: Check(if X /= null then Is_Good(X.all));
+> > -------------------------------------------^
+> > *Information* Assumed "else True", are you really sure that you want
+> > to confuse 50% of Ada programmers?? :-)
+>
+> Certainly GNAT won't give any such warning in a case like this, it
+> would generate lots of junk, so your hopefully will remain a vain
+> wish.
+> You are free to put anything you like into your compiler, but I think
+> the claim that this will confuse 50% of Ada programmers is nonsense.
+> In a case like
+>
+> Check (if bla then junk)
+>
+> I think almost all people would understand this to mean
+>
+> if bla then
+> check (junk)
+> end if;
+
+Thanks for making my point, because it *certainly* does not mean the latter.
+It means
+
+ if bla then
+ check (junk);
+ else
+ check (True);
+ end if;
+
+which may or may not be the same thing.
+
+> Note that even randy has not got to the point where he would want the
+> compiler to flag the above with
+>
+> *Information* assumed "else null", are you really sure ...
+
+Humm. This is actually a good idea, without the snark and some caveats (* see
+below). I'm going to go put it on my to-do list right now.
+
+[I can hear the ARRRGGGHHH! all the way from New York.]
+
+> To me these two contructs are entirely parallel
+
+As noted above, they don't mean at all the same thing.
+
+I can understand that some people think that leaving out the "else" is more
+readable in assertion expressions; I'm not in that group but YMMV. It the sort
+of mistake you made above (and I made in one of the messages that Bob pointed
+out) that worry me -- even the experts don't seem to *really* know what this
+means. Anyway, this is previously settled, there is no consensus for change, so
+lets not waste more time on it.
+
+(*) For the people who care why I would say that leaving out "else" should be
+warned:
+
+Our style guide requires that all if-statements end either with an else-part or
+a comment starting with "else". This was a requirement that came from other
+programmers in our organization (not me). It was a reflection that a lot of the
+bugs that we were finding in our compiler were errors of omission where you had
+code like:
+ if blah then
+ ...do great things...
+ end if;
+and no one had considered what would happen if "blah" was false. The requirement
+to add a comment at least is to signal the reader that someone did in fact
+consider the "not blah" case and determined that nothing needed to be done.
+(This is the same reason that I never use a default-initialized object in a case
+where the initialization is needed without a comment or explicit initialization.
+The only cases that I allow leaving out are "don't cares".)
+
+The comment is preferred to "else null;" because it (hopefully) tells you why
+nothing is needed. Most of time, the code really should be "else
+Internal_Error;" or "else raise Program_Error;" anyway.
+
+I've come to believe that the style guide is a bit too fierce on this issue.
+People who followed this rule religiously (and I've never been one of those)
+littered the compiler code with stuff like:
+ if Trace_Function then
+ Put_Line (...interesting stuff...);
+ -- else no trace
+ end if;
+and the else part here just adds noise. The key, for me at least, is that if the
+if-statement is really short such that it all fits in a small editor window
+(under 10 lines or so), and the condition is one that clearly needs no
+alternative part (like logging and tracing), then no comment or else part is
+really needed. (A large number of real-world if-statements are longer than 10
+lines, so that it isn't easy to see the entire thing in one window without
+scrolling around. I'd rather spend time reading rather than scrolling, as the
+latter requires taking one's hands off the keyboard home position.)
+
+So I would limit the information message only to cases where there is no
+else-part, no comment starting with "else", and the if statement is longer than
+10 lines. (Since the part about what the condition means is not something an
+automated tool can figure out.)
+
+ *Information* Assumed "else null", comment starting with "else" recommended
+
+One could imagine doing something similar with the if-expression information
+message (only triggering it if the expression appears outside of an assertion,
+because it is those cases that are most likely to be wrong, and also allowing
+comments as a stand-in).
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, December 30, 2011 3:04 PM
+
+> But bottom line for me is that the burden is heavy for changes at this
+> stage, users of the language will have had a couple of years using a
+> compiler where the implicit else true is implemented, and I don't see
+> the argument for change.
+
+I can find absolutely no support in the ISO rules for this peculiar notion that
+the existence or use of a nonstandard compiler mode creates any sort of burden
+whatsoever, let alone a heavy burden, on an ISO standardization committee in any
+stage of deliberations.
+
+You refer vaguely to the "at this stage". I think it is worth remembering that
+ISO standardization is managed using an elaborate system of stages, and that Ada
+is officially in stage 90.93 (International Standard confirmed), as of
+2008-07-29, per
+http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
+22983
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 8:43 PM
+
+> I can find absolutely no support in the ISO rules for this peculiar
+> notion that the existence or use of a nonstandard compiler mode
+> creates any sort of burden whatsoever, let alone a heavy burden, on an
+> ISO standardization committee in any stage of deliberations.
+
+Well you quote only part of what I said. I said that if there was new
+information that indicated that a change is needed, and if there is a consensus
+for such a change, then current implementations are irrelevant.
+
+Also my "heavy burden" here is a general comment. I don't think that changes
+should be made at this stage unless there is very good reason to make the
+change. I don't think that the proposal to eliminate the implicit OR ELSE even
+*vaguely* begins to meet that burden! I am not saying that the existence of an
+implementation creates that heavy burden, if you took that implication, that's
+not what I intended.
+
+> You refer vaguely to the "at this stage". I think it is worth
+> remembering that ISO standardization is managed using an elaborate
+> system of stages, and that Ada is officially in stage 90.93
+> (International Standard confirmed), as of 2008-07-29, per
+> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm
+> ?csnumber=22983
+
+Rather than making this kind of general unhelpful unconstructive comment, it
+would be more useful if you would give your opinion on the particular subject at
+hand :-)
+
+The point is that you will never converge if you keep tinkering, and especially
+you will never converge if you keep rehashing things that are already decided
+without new information. Generally in any decision procedure, you don't
+reconsider things unless at least one person changes their vote. Otherwise it's
+a waste of time.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 30, 2011 8:28 PM
+
+> WG 9 explicitly asked us to continue "fiddling with this thing"
+> through the February meeting (and no further). There was a concern
+> that it was not yet mature enough to standardize.
+
+The trouble is that what we have here is a rehash of an earlier discussion, with
+no new data or information, and therefore, in my mind, no basis for change. A
+small minority don't like this feature. That was true before. The small minority
+did not convince the majority before, and there is no reason to think that
+rehashing the same arguments will achieve anything but wasting time.
+
+I really think you don't want to reopen an old discussion that was resolved
+unless there is interesting new information, which is not the case here.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, December 30, 2011 8:52 PM
+
+> The trouble is that what we have here is a rehash of an earlier
+> discussion, with no new data or information, and therefore, in my
+> mind, no basis for change. A small minority don't like this feature.
+> That was true before. The small minority did not convince the majority
+> before, and there is no reason to think that rehashing the same
+> arguments will achieve anything but wasting time.
+
+I of course said the same thing two paragraphs later, you could have saved both
+of us some time by responding to my *entire* message rather than just the first
+two sentences.
+
+In any case, I don't agree that the "small minority" did not convince the
+"majority" before; it certainly convinced the majority to dump that "implies"
+operator in favor of the more general and more readable if-expression.
+
+> I really think you don't want to reopen an old discussion that was
+> resolved unless there is interesting new information, which is not the
+> case here.
+
+Well, *I* don't want to reopen an old discussion -- someone else did, and once
+that happens, it's not practical to stop it. (I really don't want to get into
+the censorship needed to stop such discussions.) It's going to happen from
+time-to-time; usually the re-opener has what they think is new information, but
+what turns out to have been considered by at least some people in the past.
+
+> > I do agree that this issue isn't one of those, though. This one will
+> > get filed in the AC bin (hopefully never to see the light of day).
+
+And this is still true! Even if it is in an optional else part.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, December 31, 2011 2:13 AM
+
+>> > *Information* assumed "else null", are you really sure ...
+> Humm. This is actually a good idea, without the snark and some caveats
+> (* see below). I'm going to go put it on my to-do list right now.
+
+No need to, AdaControl already has this check.
+
+Reason:
+Some programming standards are slavishly copied from C, where the required "else
+;" is used to avoid bad matches between "if" and "else".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, December 31, 2011 2:26 AM
+
+> No need to, AdaControl already has this check.
+
+Of course there is a need, it's not in Janus/Ada yet.
+
+> Reason:
+> Some programming standards are slavishly copied from C, where the
+> required "else ;" is used to avoid bad matches between "if" and
+> "else".
+
+And it doesn't sound like your rule would suppress the warning if a properly
+formatted comment is in place of the else. That's important to match our style
+guide (and keep the requirement from being pure noise in many cases). As I said,
+the reason we require it (mostly) is to reduce errors of omission by ensuring
+that all cases have been considered.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 31, 2011 6:37 AM
+
+>>>> *Information* assumed "else null", are you really sure ...
+>> Humm. This is actually a good idea, without the snark and some
+>> caveats (* see below). I'm going to go put it on my to-do list right now.
+> No need to, AdaControl already has this check.
+
+Yes, well like gnatcheck, AdaControl is full of misguided rules that come from
+idiosyncratic coding standard rules. It doesn't mean these rules are a good
+idea, and certainly does not mean they should be incorporated into compilers,
+which is what Randy was saying.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, December 31, 2011 5:18 PM
+
+Hey, my style rules are *always* a good idea. :-)
+
+Seriously, since you didn't comment on my detailed explanation of the our style
+rule (it's more complex than the na‹ve rule that J-P is talking about), I really
+have no idea why you think it is a bad idea. It's really not much different than
+the case completeness check, which everyone thinks is a good idea. Missing
+"else" was a major cause of bugs in our compiler code in the early 1990's, and
+adopting this style rule reduced that problem by a lot.
+
+In any case, what makes sense for our compiler (and I was *only* talking about
+adding it to our compiler) probably differs from what makes sense in your
+compiler. Janus/Ada is verbose (some might say "chatty"), and it reports all
+kinds of things that the user might be interested in knowing. Just because it
+reports something does not mean that it needs to be changed (a warnings = errors
+mode would be a disaster in Janus/Ada, you'd hardly be able to write anything).
+You can turn them off, of course, but I don't think many people do. [Aside: I've
+been thinking about making the importance of messages clearer in Janus/Ada,
+because there is some chance of missing something more important in the less
+important messages. But I wouldn't get rid of those messages, they're often
+helpful.]
+
+YMMV, of course.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 31, 2011 5:40 PM
+
+In our experience false positives are a major source of concern for warnings. if
+warnings generate a lot of false positives, then people just turn them off,
+since it is too much trouble to go through them if you have a legacy system with
+millions of lines of code
****************************************************************
Questions? Ask the ACAA Technical Agent