CVS difference for ai05s/ai05-0147-1.txt
--- ai05s/ai05-0147-1.txt 2009/07/11 03:06:22 1.3
+++ ai05s/ai05-0147-1.txt 2009/10/29 08:08:09 1.4
@@ -1,4 +1,4 @@
-!standard 4.4 (07) 09-06-27 AI05-0147-1/03
+!standard 4.4 (07) 09-10-28 AI05-0147-1/04
!standard 4.5.7 (0)
!standard 4.7(2)
!standard 4.7(3)
@@ -46,7 +46,9 @@
One could write a local function to evaluate the expression properly, but that
doesn't work if the expression is used in a context where it has to be static
-(such as specifying the size of a subtype).
+(such as specifying the size of a subtype). In addition, a local function
+requires putting the expression in a body, possibly requiring the addition
+of a body to an otherwise subprogram-less package.
A conditional expression would make writing this expression easy:
@@ -114,7 +116,7 @@
Legality Rules
-If there is no "else" dependent_expression, the type of conditional_expression
+If there is no "else" dependent_expression, the type of the conditional_expression
shall be of a boolean type.
Dynamic Semantics
@@ -161,8 +163,8 @@
* it is part of the right operand of a static short-circuit control form whose value
is determined by its left operand;
* it is part of a condition of some part of a conditional_expression, and at
- least one and at least one condition of a preceeding part of the
- conditional_expression has the value True; or
+ least one condition of a preceeding part of the conditional_expression has the
+ value True; or
* it is part of the dependent_expression of some part of a
conditional_expression, and the associated condition evaluates to False; or
* it is part of the dependent_expression of some part of a
@@ -215,12 +217,12 @@
Ada), or using syntax other than "if", would be less familar and would cause
programmers a confusion as to which syntax to use in a given location.
-Thus, we design conditional expressions work like and look like aggregates. This
-the reason that they are defined to be a primary rather than some other sort of
-expression. The fact that the parentheses are required makes this preferable (it
+Thus, we design conditional expressions to work like and look like aggregates.
+This is the reason that they are defined to be a primary rather than some other sort
+of expression. The fact that the parentheses are required makes this preferable (it
would be confusing otherwise).
-One could imagine rules allowing the parenthesis being omitted in contexts where
+One could imagine rules allowing the parentheses being omitted in contexts where
they are not needed, such as a pragma argument. However, this would add
conceptual overhead - it important to note that this was not done for aggregates
except in the case of qualified expressions. It also would make syntax error
@@ -234,8 +236,8 @@
likely too late for the compiler to determine that the real error occurred much
earlier. Nor would it be easy for the programmer to see where the error is.
(Remember that Foo and B can be arbitrarily complex and on multiple lines.) With
-a required parenthesis, syntax correction would either identify the parenthesis
-or the expression as missing, showing the correct point of the error.
+a required parenthesis, syntax correction would either identify the required
+parenthesis or the expression as missing, showing the correct point of the error.
Following the model of aggregates also simplifies the resolution of conditional
@@ -268,9 +270,9 @@
expressions. This eases the use of conditional expressions in preconditions
and postconditions, as it provides a very readable form of the "implies"
relationship of Boolean algebra. That is,
- A implies B
+ Assert that A implies B
could be written as
- (if A then B)
+ pragma Assert(if A then B)
In this case, the "else" branch is more noise than information.
@@ -2868,5 +2870,1526 @@
model for them, at least syntactically.
All comments welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, March 15, 2009 8:03 AM
+
+Thanks, Randy. I have concluded that this is
+*much* more important than "implies" or equivalent, as I believe these will
+be heavily used in preconditions and postconditions. There are a lot of
+interesting preconditions and postconditions you simply can't state without
+using a conditional expression.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, March 15, 2009 8:20 AM
+
+I agree with this, but actually the use in PPC's seems only a part of what these
+bring, it is annoying to have to write:
+
+ if bla then
+ lhs := 3;
+ else
+ lhs := 4;
+ end if;
+
+where lhs is the same (possibly complex) lhs. much cleaner and clearer to write
+
+ lhs := (if bla then 3 else 4);
+
+I must say I still like to abstract complex conditionals into predicate
+functions. People manage to write frighteningly complex conditions without this
+feature, and I am afraid that this will get worse with the addition of this
+feature. Still possible misuse is not a reason for prohibition!
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Sunday, March 15, 2009 9:07 AM
+
+> where lhs is the same (possibly complex) lhs. much cleaner and clearer
+> to write
+>
+> lhs := (if bla then 3 else 4);
+
+Agreed, this will be used abundantly. I like the default boolean True
+interpretation when the else part is missing.
+
+Not convinced about the need for case expressions, but would like to see a
+similar proposal for what Randy calls loop expressions, i.e. quantified
+expressions.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, March 15, 2009 10:22 AM
+
+BTW, for the record on the implies thread, I am much more amenable to adding
+implies if it is not spelled with the confusing keyword "implies". So something
+like
+
+ a -> b
+
+would be much more acceptable to me :-)
+
+****************************************************************
+
+From: Stephen Michell
+Sent: Sunday, March 15, 2009 12:46 PM
+
+For the record, I believe that "implies" or "->" should definitely be added.
+From Randy's AI, saying
+ if A then B else TRUE is just difficult way of saying A -> B.
+One problem with the if-then-else comes with conjunctions, such as
+ A -> B, C-> D, E -> F
+It is easy to see that
+ A->B and C->D and E->F
+which could easily be converted to
+ (if A then B else True) and (if C then D else True) and (if E then F else True)
+but many people are going to try to do it all with if-then-elsif-else
+constructs, which becomes very messy.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 2:28 PM
+
+> For the record, I believe that "implies" or "->" should definitely be
+> added. From Randy's AI, saying
+> if A then B else TRUE is just difficult way of saying A -> B.
+
+No, note that the proposal says "else True" is optional.
+So "A -> B" means "A implies B", which means "if A then B", which means "if A
+then B else True". I think "if A then B" is a good way of saying what's meant.
+
+> One problem with the if-then-else comes with conjunctions, such as
+> A -> B, C-> D, E -> F
+> It is easy to see that
+> A->B and C->D and E->F
+> which could easily be converted to
+> (if A then B else True) and (if C then D else True) and (if E then F
+> else True)
+
+That should be:
+ (if A then B) and (if C then D) and (if E then F)
+
+Or use "and then", if you prefer. I wouldn't normally put that in an 'if'
+statement, but in an assertion, it reads just fine. Or I might write:
+
+ pragma Assert(if A then B);
+ pragma Assert(if C then D);
+ pragma Assert(if E then F);
+
+(Of course I realize Randy wants double parens there. No big deal.)
+
+> but many people are going to try to do it all with if-then-elsif-else
+> constructs, which becomes very messy.
+>
+> Robert Dewar wrote:
+> > BTW, for the record on the implies thread, I am much more amenable
+> > to adding implies if it is not spelled with the confusing keyword
+> > "implies". So something like
+> >
+> > a -> b
+> >
+> > would be much more acceptable to me :-)
+
+I've no idea why Robert thinks "->" is more readable and less confusing than
+"implies". I mean, we don't use "^" and "|" for "and" and "or". We prefer the
+English words. Like "xor" (ha ha!)
+
+I say, leave out "implies" or "->" (or however it's spelled) from the language.
+The proposed conditional expression does the job quite nicely.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, March 15, 2009 3:52 PM
+
+The problem with "implies" is that it
+really doesn't read well with assertions or preconditions. You should try a few
+preconditions. They always seem a bit confusing when you use "implies".
+What you are really trying to convey is
+that "if blah is true" then this is a precondition.
+That is admittedly equivalent to "blah implies this"
+but it isn't really a general "implication"
+in the logic sense. It is simply a precondition that only applies some of the
+time.
+
+And for postconditions, you quite often want a conditional expression with an
+"else". For example, how would you express the postcondition of a max function
+without a conditional expression (presuming you didn't have a 'Max attribute!).
+
+I think if we agree on having an else-less boolean conditional-expression, then
+we get the best of both worlds -- something that is equivalent to "implies" but
+captures the meaning better in an precondition, which based on a general
+conditional-expression syntax that we will need for postconditions.
+
+If you drop the "else True" your example doesn't seem so bad:
+
+ (if A then B) and
+ (if C then D) and
+ (if E then F)
+
+Or depending on the relationships between the clauses, it might become:
+
+ (if A then B elsif
+ C then D elsif
+ E then F)
+
+I'll admit I still have a slight preference for omitting the initial "if":
+
+ (A then B) and (C then D) and (E then F)
+
+or
+
+ (A then B elsif C then D elsif E then F)
+
+It just seems more symmetrical to leave off the initial "if" since I think we
+all agree we want to leave off the trailing "endif". And the "if" seems pretty
+obvious when you start off with a boolean condition. Here is an example of a
+postcondition using a conditional expression:
+
+ function Max(X, Y : T) return T
+ Post =>
+ Max'Result = (X >= Y then X else Y);
+
+Here is an example of a precondition:
+
+ function Copy_Tree(T : Tree) return Tree
+ Pre =>
+ (T /= null then (T.Left'Initialized and T.Right'Initialized));
+
+The "if" seems unnecessary in both cases.
+
+I would agree with Robert that "->" is preferable to "implies" as it seems to
+avoid some of the confusion inherent in the word "implies," but unfortunately I
+fear we would get stalled in discussions about short-circuiting, which I think
+is a waste of breath at this point. Whereas with "then," we have an existing
+reserved word, and one for which there is no confusion about the order of
+evaluation.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, March 15, 2009 4:55 PM
+
+> I think if we agree on having an else-less boolean
+> conditional-expression, then we get the best of both worlds --
+> something that is equivalent to "implies" but captures the meaning
+> better in an precondition, which based on a general
+> conditional-expression syntax that we will need for postconditions.
+
+This usage argument is a strong one for allowing elseless if conditions.
+
+...
+> I'll admit I still have a slight preference for omitting the initial
+> "if":
+>
+> (A then B) and (C then D) and (E then F)
+>
+> or
+>
+> (A then B elsif C then D elsif E then F)
+
+I prefer it with the initial IF.
+
+> It just seems more symmetrical to leave off the initial "if" since I
+> think we all agree we want to leave off the trailing "endif". And the
+> "if"
+> seems pretty obvious when you start off with a boolean condition.
+> Here is an example of a postcondition using a conditional expression:
+
+Yes, but you don't always know it's a boolean condition when you start off, and
+if the expression is
+
+ bool_var := (long_boolean_expression then ...
+
+it takes a while of left to right reading to understand that you have a
+conditional expression
+
+I don't buy the symmetry argument! You read left to right, so the IF on the left
+is much more important than the END IF on the right, when you already know you
+are in an IF.
+
+> I would agree with Robert that "->" is preferable to "implies" as it
+> seems to avoid some of the confusion inherent in the word "implies,"
+> but unfortunately I fear we would get stalled in discussions about
+> short-circuiting, which I think is a waste of breath at this point.
+> Whereas with "then," we have an existing reserved word, and one for
+> which there is no confusion about the order of evaluation.
+
+If -> is provided, it definitely should short circuit, but all-in-all I agree
+with Tuck that if we have the conditional expressions we don't need implies.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, March 16, 2009 8:41 AM
+
+> Also do we have
+>
+> (exists E in A : F(E) > 0)
+>
+And if we go further, we could write:
+ [ x in [1..N] | not exists y in [2..x-1] | x mod y = 0]
+
+Are you sure we are still talking about Ada? ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, March 16, 2009 9:04 AM
+
+Unicode can help here:
+
+ ? 2200, FOR ALL , forall, ForAll
+ ? 2203, THERE EXISTS , exist, Exists
+ ? 02204, THERE DOES NOT EXIST , nexist, NotExists, nexists
+
+I agree with Robert that these might be appropriate uses of Unicode. Certainly
+minimizes the upward compatibility issue.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 9:29 AM
+
+> In the interests of making myself more work that I may never get paid
+> for, below find a *complete* write-up for conditional expressions.
+
+Thanks. Looks great.
+
+> One could write a local function to evaluate the expression properly,
+> but that doesn't work if the expression is used in a context where it
+> has to be static (such as specifying the size of a subtype).
+
+It also doesn't work very well in a package spec.
+
+...
+> [Editor's Note: "condition" is defined in 5.3. Should it (both syntax
+> and semantics - 2 lines) be moved here to avoid the forward
+> reference??]
+
+Probably.
+
+> Legality Rules
+>
+> If there is no "else" dependent_expression, the type of
+> conditional_expression shall be of a boolean type.
+
+Too many "of"'s here, and not enough "the"'s. Either "the
+conditional_expression shall be of a boolean type" or "the type of the
+conditional_expression shall be a boolean type".
+
+Or do we want, "the expected type for the conditional_expression shall be a
+boolean type"?
+
+...
+> Split 4.9(33), replacing it by the following:
+>
+> A static expression is evaluated at compile time except when:
+> * it is part of the right operand of a static short-circuit control
+> form whose value
+> is determined by its left operand;
+> * it is part of a condition of some part of a conditional_expression,
+> and at
+> least one and at least one condition of a preceeding part of the
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^written by the DOR Department.
+> conditional_expression has the value True; or
+> * it is part of the dependent_expression of some part of a
+> conditional_expression, and the associated condition evaluates to
+> False; or
+> * it is part of the dependent_expression of some part of a
+> conditional_expression, and at least one condition of a preceeding
+> part of
+> the conditional_expression has the value True.
+
+The above seems right, but I find it confusing. Maybe something like this would
+be better:
+
+A static expression that is not a subexpression is evaluated at compile time. If
+a static expression is evaluated at compile time, all of its operands [immediate
+subexpressions?] are also evaluated at compile time, except:
+
+ For a short-circuit control form, the left operand is evaluated. The right
+ operand is evaluated only if the left operand does not determine the value
+ of the s-c c.f.
+
+ For a conditional expression, the condition specified after
+ if, and any conditions specified after elsif, are evaluated in succession
+ (treating a final else as elsif True then), until one evaluates to True or
+ all conditions are evaluated and yield False. If a condition evaluates to
+ True, the associated dependent_expression is evaluated.
+
+(Maybe we need to define "subexpression" and/or "operand".)
+
+> AARM Reason: We need the last bullet so that only a single
+> dependent_expression is evaluated if there is more than one condition
+> that evaluates to True.
+> End AARM Reason.
+>
+> The compile-time evaluation of a static expression is performed
+> exactly, without performing Overflow_Checks. For a static expression
+> that is evaluated:
+>
+> [Editor's note: Adam Beneschan suggested in AC-0171 to add another
+> cases to this list - an aggregate others clause known to denote zero
+> elements:
+>
+> * it is part of the expression of an array_component_association whose
+> discrete_choice_list is statically known to denote zero
+> components.
+>
+> I don't think this level of detail is common enough to add to the
+> language, but the rewrite of this paragraph would make it easy to add
+> here if desired.]
+
+Actually, why don't we just get rid of this concept of "evaluated at compile
+time"? Does it actually mean anything? I mean, is there an ACATS that can tell
+the difference?
+
+The above is a lot of verbiage for a concept that doesn't mean anything.
+
+> Thus, we design conditional expressions work like and look like aggregates.
+ ^ to
+
+> This
+ ^ is
+
+> the reason that they are defined to be a primary rather than some
+> other sort of expression. The fact that the parentheses are required
+> makes this preferable (it would be confusing otherwise).
+>
+> One could imagine rules allowing the parenthesis being omitted in
+> contexts
+ parentheses
+
+> where
+> they are not needed, such as a pragma argument. However, this would
+> add conceptual overhead - it important to note that this was not done
+> for aggregates except in the case of qualified expressions. It also
+> would make syntax error correction much harder. Consider the following
+> syntactically incorrect Ada
+> code:
+>
+> exit when if Foo then B := 10; end if;
+>
+> Currently, syntax error correction most likely would identify a
+> missing expression and semicolon. With the conditional expression
+> syntax without parentheses, the syntax is correct up until the ":=",
+> at which point it is likely too late for the compiler to determine
+> that the real error occurred much earlier. Nor would it be easy for
+> the programmer to see where the error is.
+> (Remember that Foo and B can be arbitrarily complex and on multiple
+> lines.) With a required parenthesis, syntax correction would either
+> identify the
+ required parentheses
+
+> parenthesis
+> or the expression as missing, showing the correct point of the error.
+
+I agree, regarding the above example of "exit". But it would be nice if we could say:
+
+ pragma Assert(if A then B);
+
+and:
+
+ Assert(if A then B); -- Here, Assert is a procedure.
+
+> Following the model of aggregates also simplifies the resolution of
+> conditional expressions. This avoids nasty cases of resolution, in
+> which a compiler might be able to figure out a unique meaning but a
+> human could not. For instance, given the declarations:
+>
+> procedure Q (A, B : Integer);
+> procedure Q (A, B : float);
+>
+> function F return Integer;
+> function F return Boolean;
+>
+> function G (N : Natural) return Integer;
+> function G (N : Natural) return Float;
+>
+> Q (if X > 3 then F else G(1)), (if X > 12 then G(2) else G(3)));
+>
+> If we used full resolution, this would resolve to Integer because
+> there is no F for Float. With the unlimited number of terms available
+> in a conditional expression, one can construct ever more complex
+> examples.
+>
+> Should we eventually find this to be too restrictive, changing to a
+> full resolution model would be compatible (it would only make illegal
+> programs legal), whereas going in other direction is would be
+> incompatible. So it is best to start with the more restrictive rule.
+
+Agreed, but I'm pretty sure I will never want to relax this rule.
+
+> We allow the "else" branch to be omitted for boolean-valued
+> conditional expressions. This eases the use of conditional expressions
+> in preconditions and postconditions, as it provides a very readable form of the "implies"
+> relationship of Boolean algebra. That is,
+> A implies B
+> could be written as
+> (if A then B)
+> In this case, the "else" branch is more noise than information.
+
+The point would be clearer if you say:
+
+ pragma Assert(A implies B);
+could be written as
+ pragma Assert((if A then B));
+
+(Or "pragma Assert(if A then B);", if you take my syntax suggestion above.)
+
+Because I suspect boolean conditional expressions are primarily useful in
+assertions (by which I mean to include preconditions and so forth). I don't see
+much use for:
+
+ if (if A then B) then
+ ...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 9:32 AM
+
+> Thanks, Randy. I have concluded that this is
+> *much* more important than "implies" or equivalent, as I believe these
+> will be heavily used in preconditions and postconditions. There are a
+> lot of interesting preconditions and postconditions you simply can't
+> state without using a conditional expression.
+
+Agreed. So let's forget about adding "implies", because:
+
+ 1. Some people find it confusing.
+
+ 2. To folks like me, who do not find it confusing, it's not important to have,
+ once we have conditional expressions.
+
+ 3. New reserved words should not be added unless they provide some important
+ benefit, and certainly not for negative benefit, as (1) implies.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 9:46 AM
+
+> Agreed, this will be used abundantly. I like the default boolean True
+> interpretation when the else part is missing.
+
+Me, too.
+
+> Not convinced about the need for case expressions,
+
+I am. (I suppose this means I have to write it up? Bleah. ;-))
+
+The full-coverage/no-duplicate rules are one of the huge benefits of Ada
+-- perhaps my favorite feature. So if I currently have:
+
+ procedure (...) is
+ begin
+ case ... is
+ when This =>
+ Assert (...);
+ when That =>
+ Assert (...);
+ ...
+
+I want to convert that into a precondition, but I don't want to convert into a
+chain of elsif's, thus losing full coverage. When I add a new enumeration
+literal, I might forget to update the precondition.
+
+Note that I left out the noise words, "null; pragma " above. ;-)
+
+>...but would like to
+> see a similar proposal for what Randy calls loop expressions, i.e.
+> quantified expressions.
+
+I've no idea what quantified expressions should look like or mean, so I too
+would like to see a proposal. Didn't Cyrille volunteer to send one to
+ada-comment?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 9:37 AM
+
+> I must say I still like to abstract complex conditionals into
+> predicate functions.
+
+Agreed. Which means that if you want to use a conditional in a precondition,
+you (sometimes) want to put the BODY of a boolean function in a package SPEC, so
+it is not hidden from the compiler!
+
+[Editor's note: Replies to this part of the message are found in AC-00180.]
+
+>...People manage to write
+> frighteningly complex conditions without this feature, and I am
+>afraid that this will get worse with the addition of this feature.
+
+No doubt.
+
+>...Still possible misuse is
+> not a reason for prohibition!
+
+Agreed. Can I quote you on that when discussing other unrelated issues? ;-) I
+think it's a general principle: if you try to prevent misuse, you will also
+prevent good use. Preventing misuse is the job of educators and code reviewers,
+not language designers.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, March 15, 2009 4:39 PM
+
+> I'll admit I still have a slight preference for omitting the initial
+> "if":
+
+Yuck. I agree with everything else you wrote, but I just can't stomach leaving
+off the 'if'.
+
+>... And the "if"
+> seems pretty obvious when you start off with a boolean condition.
+
+The problem is, I don't immediately see it as a boolean condition, unless I see
+the 'if' first. Please keep the 'if' syntax on conditional expressions!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 16, 2009 9:38 AM
+
+> Unicode can help here:
+>
+> ? 2200, FOR ALL , forall, ForAll
+> ? 2203, THERE EXISTS , exist, Exists
+> ? 02204, THERE DOES NOT EXIST , nexist, NotExists, nexists
+>
+> I agree with Robert that these might be appropriate uses of Unicode.
+> Certainly minimizes the upward compatibility issue.
+
+I would strongly object to having these features available _only_ through
+non-7-bit-ascii characters. I don't know how to type ?, and I don't want to
+learn. And to this day, misc software displays all kinds unicode stuff wrong.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 16, 2009 1:58 PM
+
+...
+> Actually, why don't we just get rid of this concept of "evaluated at
+> compile time"? Does it actually mean anything?
+> I mean, is there an ACATS that can tell the difference?
+>
+> The above is a lot of verbiage for a concept that doesn't mean
+> anything.
+
+Not true: an evaluated static expression that would raises an exception is
+statically illegal. Thus, if we didn't have this wording, (for I and J static):
+
+ I /= 0 and then J/I > 5 -- Would be illegal if I = 0
+
+ (if I /= 0 then J/I > 5 else True) -- Would be illegal if I = 0
+
+So it should be obvious that we *do* need this wording and concept.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 16, 2009 2:11 PM
+
+>>...Still possible misuse is
+>> not a reason for prohibition!
+
+>Agreed. Can I quote you on that when discussing other unrelated issues? ;-)
+>I think it's a general principle: if you try to >prevent misuse, you
+>will also
+>prevent good use. Preventing misuse is the job of educators and code
+>reviewers, not language designers.
+
+So you are saying that strong typing is a mistake? ;-)
+
+Obviously, there is a balance between preventing *likely* misuse and *rare*
+misuse - you want rules to prevent the former and not the latter. My point is
+that this is not a black-and-white decision, so taking Robert's statement out of
+context is pointless (and harmful).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 16, 2009 2:14 PM
+
+> The problem is, I don't immediately see it as a boolean condition,
+> unless I see the 'if' first. Please keep the 'if'
+> syntax on conditional expressions!
+
+I agree strongly with Bob. This is the same reason for not omitting the parens:
+syntax understanding (and thus syntax error correction) requires early
+determination of the difference between a "normal" boolean expression and a
+conditional expression, just like it does between an if statement and a
+conditional expression. I think everything I wrote about the latter would also
+apply to the former.
+
+After all, I did use all of the *good* ideas from Tucker's proposal, so the fact
+that I didn't use that one should indicate what I thought about it...
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, March 16, 2009 3:18 PM
+
+>> I'll admit I still have a slight preference for omitting the initial
+>> "if":
+>
+> Yuck. I agree with everything else you wrote, but I just can't
+> stomach leaving off the 'if'.
+
+I support that Yuck. Actually, I had to mentally add an "if" in front of the
+expression to be able to understand it.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, March 16, 2009 5:34 PM
+
+> So you are saying that strong typing is a mistake? ;-)
+
+Not at all. Ada's type rules do not "prevent misuse", they just make mistakes
+less likely. You can always bypass the type system using Unchecked_Conversion
+and other chap-13-ish features. To me, "misuse" implies some deliberate (but
+foolish/misguided) action.
+
+"Prevent misuse" would imply (for example) outlawing Unchecked_Conversion. I'm
+against that, despite the fact that I have seen misuse of Unchecked_Conversion.
+
+"Prevent mistakes" means "require the programmer to say something explicit, like
+'with Unchecked_Conversion', when using this dangerous feature". I'm in favor of
+trying to prevent mistakes, and I'm in favor of requiring documentation of
+questionable or dangerous things, which is exactly what "with U_C" does.
+
+> Obviously, there is a balance between preventing *likely* misuse and
+> *rare* misuse - you want rules to prevent the former and not the latter.
+
+I don't agree, but I think you're just using "misuse" in a different way than I.
+
+>...My point
+> is that this is not a black-and-white decision, so taking Robert's
+>statement out of context is pointless (and harmful).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 16, 2009 7:37 PM
+
+...
+> > >I think it's a general principle: if you try to prevent misuse, you
+> > >will also prevent good use. Preventing misuse is the job of
+> > >educators and code reviewers, not language designers.
+> >
+> > So you are saying that strong typing is a mistake? ;-)
+>
+> Not at all. Ada's type rules do not "prevent misuse", they just make
+> mistakes less likely. You can always bypass the type system using
+> Unchecked_Conversion and other chap-13-ish features. To me, "misuse"
+> implies some deliberate (but
+> foolish/misguided) action.
+
+One person's "mistake" is another person's "misuse". You seem to be arguing both
+sides here: prevent what I think is a "mistake", but allow what I think is a
+"misuse". I just don't see such a black-and-white line here. (Well, at least if
+I'm trying to be an impartial language standard editor -- my personal opinions
+may vary. :-)
+
+After all, a type error is often just a misguided action.
+
+ Flt : Float := 1.0;
+ ...
+ Flt := Flt + 1;
+
+is a "mistake" in Ada. But it makes perfect sense - it is just a type error
+preventing you from doing something. (Replace "1" with "Int_Var" if you don't
+like the literal example. It's hard to see what the "mistake" is in this
+example.
+
+So I don't see any reason to try to classify things into "mistakes" and
+"misuses". They're just a continuum of programming errors.
+
+> "Prevent misuse" would imply (for example) outlawing Unchecked_Conversion.
+> I'm against that, despite the fact that I have seen misuse of
+> Unchecked_Conversion.
+>
+> "Prevent mistakes" means "require the programmer to say something
+> explicit, like 'with Unchecked_Conversion', when using this dangerous
+> feature".
+> I'm in favor of trying to prevent mistakes, and I'm in favor of
+> requiring documentation of questionable or dangerous things, which is
+> exactly what "with U_C" does.
+
+Which are just two points on the continuum of choices; they're both trying to
+preventing errors in different ways. The first would be outright banning of a
+relatively rare programming error; the second is trying to discourage the use of
+the feature without banning it.
+
+> > Obviously, there is a balance between preventing *likely* misuse and
+> > *rare* misuse - you want rules to prevent the former and not the latter.
+>
+> I don't agree, but I think you're just using "misuse" in a different
+> way than I.
+
+I don't see any difference between a "mistake" and "misuse", and apparently you
+do. They're the same thing to me. There are just degrees of wrongness: *likely*
+mistake/misuse vs. *rare* mistake/misuse.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, March 17, 2009 8:36 AM
+
+I have been away from my desk for a bit and on my return am totally overwhelmed
+by ARG mail.
+
+And a big problem is that this thread seems to have changed into a completely
+different topic.
+
+Let me say that I really missed conditional expressions in Ada having used them
+widely in Algol 60 and would vote for them if put in nicely.
+
+But I seem to be seeing all sorts of strange notions like omitting end if and
+even omitting if. It all seems very ugly and turning Ada into a hieroglyphic
+mess.
+
+Just where are we going? Can somone do a very brief summary?
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 8:50 AM
+
+I suspect the "if" at the beginning stays (it's N to 1 in favor, with N >> 1). The closer does seem superfluous,
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 8:48 AM
+
+Current thinking is (IF condition THEN expr
+ {ELSIF condition THEN expr}
+ [ELSE expr])
+
+If ELSE expr is omitted, it means ELSE TRUE (convenient for the implication
+case).
+
+No one has even suggested END IF being included, and I would definitely be
+opposed to that suggestion, It is unnecessary syntactic clutter, and the END
+keyword is fundamental in error recovery and should not be allowed in the middle
+of expressions!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 9:23 AM
+
+One remaining question is whether un-parenthesized conditional expressions would
+be permitted in some contexts, such as parameters in a call, and other contexts
+where they would follow "=>", to avoid the annoyance of double parentheses and
+the LISP-like appearance.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, March 17, 2009 9:41 AM
+
+My personal preference would be (as mentionned before) "like aggregates", i.e.
+no double parentheses only in qualified expressions.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 9:47 AM
+
+I don't understand, aggregates do require the double parens, the question is,
+can you right
+
+ X (if A then B else C)
+
+Surely you are not sugegsting that we ALWAYS have to qualify these expressions?
+If so, I strongly object, it would be absurd to have to write
+
+ pragma Precondition (Boolean'(if A then B));
+
+now the question is, can we write
+
+ pragma Precondition (if A then B);
+
+or do we have to write
+
+ pragma Precondition ((if A then B));
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, March 17, 2009 10:37 AM
+
+>> My personal preference would be (as mentionned before) "like
+>> aggregates", i.e. no double parentheses only in qualified expressions.
+>
+> I don't understand, aggregates do require the double parens
+Not in qualified expressions, i.e. T'(...)
+
+I said the same should apply to "if expression", no more, no less.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 10:36 AM
+
+I think what JP meant was that, as with the special case for aggregates in
+qualified expressions, a qualified expression whose operand is a conditional
+expression would not require double parentheses. Elsewhere, JP doesn't seem
+worried about double parentheses, though some of us seem to disagree with him
+(mildly, it seems). I think we would all agree that qualified expressions
+should not require double parentheses if the operand is a conditional
+expression.
+
+JP, did I convey your intent properly?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 10:46 AM
+
+Sure they require the double parens:
+
+ X (T'(...))
+
+is what we mean by double parens!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 10:49 AM
+
+Ah, OK, that makes sense, yes of course we don't need F (Integer'((if A then 1
+else 2)));
+
+Even F (Integer'(if A then 1 else 2))
+
+seems horrible to me, I don't see why we can't resolve this properly without the
+qualification, seems trivial to me, although I have not spent much time delving
+into resolution. Though Ed Schonberg (our primary delver into such matters),
+also declares this trivial, and in fact we already do it for conditional
+expressions (we would have to undo stuff to implement this nasty restriction).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 11:04 AM
+
+JP was not suggesting that a qualified expression was required, merely that *if*
+you chose to use one, then you wouldn't be burdened with yet another set of
+parentheses. Just like aggregates, the RM wouldn't require a qualified
+expression so long as the expected type for the conditional expression was a
+"single" type.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 11:43 AM
+
+OK, that's not how I interpreted his message, so how about we let JP clarify?
+:-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 17, 2009 11:58 AM
+
+JP did clarify, and his clarification matches Tucker's interpretation.
+
+There are two separate issues related to qualified expressions, which I think
+you are confusing:
+
+ 1. Syntax. Randy proposed it should be "just like aggregates",
+ which means you have to put parens around a conditional
+ expression, except there's a special case in the BNF for qualified
+ expressions that allows you to omit one layer of parens.
+ JP agrees with Randy. Tucker and I would like to allow
+ omitting parens in a few more cases (but I don't feel
+ strongly).
+
+ 2. Overload resolution. Randy proposed it should be "just like
+ aggregates", which means the expected type must be a "single type".
+ That means you have to stick in some qualifications where you
+ otherwise wouldn't have to. I agree with Randy on this.
+ I think Tucker does, too. You disagree. I don't think
+ JP said anything about this issue.
+
+Note that my opinion on (2) is based on readability, so your claims that it's
+trivial to implement without the "single type" rule don't sway me, even if they
+are true (which I doubt -- note that you'd have to intersect an arbitrary number
+of types when you have elsif chains).
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, March 17, 2009 10:55 AM
+
+> Current thinking is (IF condition THEN expr
+> {ELSIF condition THEN expr}
+> [ELSE expr])
+>
+> If ELSE expr is omitted, it means ELSE TRUE (convenient for the
+> implication case).
+>
+> No one has even suggested END IF being included, and I would
+> definitely be opposed to that suggestion, It is unnecessary syntactic
+> clutter, and the END keyword is fundamental in error recovery and
+> should not be allowed in the middle of expressions!
+
+Yes I suppose it's different to Algol68 where the closer was simply FI (if
+backwards) and no end in sight.
+
+So the else part can only be omitted when the type is Boolean. Hmmm.
+
+Thanks for summary.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 1:07 PM
+
+> Yes I suppose it's different to Algol68 where the closer was simply FI
+> (if
+> backwards) and no end in sight.
+
+Actually, it's more normal in Algol68 to use the short form
+
+ (b | c |: d | e | f)
+
+for conditional expressions at least short ones, so for example
+
+ (b > 0 | 3 / b | 0)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, March 17, 2009 12:16 PM
+
+> JP, did I convey your intent properly?
+
+Yes, and so did Bob.
+
+My concern is not to have a set of different rules. It is better if we can build
+on existing rules, although not perfect. For aggregates, we can write:
+ T'(1 => 'a', 2 => 'b')
+but we must write:
+ Put ((1 => 'a', 2 => 'b'));
+
+It would be strange to be able to write
+ Put (if B then 1 else 2);
+but not:
+ Put (1 + if B then 1 else 2);
+because of the ambiguity with:
+ Put (if B then 1 else 2 + 1)
+(unless you want to add an extra level of precedence, but I think it would be
+too error-prone)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 12:49 PM
+
+> Note that my opinion on (2) is based on readability, so your claims
+> that it's trivial to implement without the "single type" rule don't
+> sway me, even if they are true (which I doubt -- note that you'd have
+> to intersect an arbitrary number of types when you have elsif chains).
+
+Intersecting types of candidate interpretations is the natural thing to do in
+several places during resolution, so this just falls out from existing
+machinery. The rule is simple to state as a name resolution rule:
+
+if the else part is missing, the expected type of each expression, and the
+expected type of the conditional expression itself, is Boolean Otherwise the
+expected type of each expression is any type, and all the expressions must
+resolve to the same type.
+
+These things are homogeneous, unlike aggregates, and it's natural to state the
+rule in terms of that uniformity.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 1:10 PM
+
+> It would be strange to be able to write
+> Put (if B then 1 else 2);
+> but not:
+> Put (1 + if B then 1 else 2);
+
+Not to me, it seems reasonable to require parens in the second case, exactly
+because of possible ambiguity
+
+I am inclined to remove the parens in pragma arguments, (so pragma Precondition
+works nicely), and in subprogram calls.
+
+BTW: I am a little concerned that by the time the ARG/WG9/ISO machinery finally
+publishes precondition/postcondition in Tucks alternative syntactic form, the
+use of the pragmas will be so wide-spread that the new form will have little
+relevance. It is also a huge advantage that the pragmas can be used with any
+version of Ada, whereas the new syntax would require an immediate commitment to
+Ada 201x mode).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, March 17, 2009 1:41 PM
+
+> There are two separate issues related to qualified expressions, which
+> I think you are confusing:
+
+Thanks for stating the issues so clearly.
+
+>
+> 1. Syntax. Randy proposed it should be "just like aggregates",
+> which means you have to put parens around a conditional
+> expression, except there's a special case in the BNF for qualified
+> expressions that allows you to omit one layer of parens.
+> JP agrees with Randy. Tucker and I would like to allow
+> omitting parens in a few more cases (but I don't feel
+> strongly).
+>
+
+I'm torn on this one.
+
+The parens in this example
+
+ pragma Assert ((if A then B else C));
+
+look a bit odd, but we certainly don't want to allow
+
+ begin
+ P (if A then B elsif C then D, if E then F elsif G then H else I);
+
+The problem is where to draw the line.
+
+The proposed "just like aggregates" rule builds on precedent, adds to language
+consistency, and seems like a reasonable choice. On the other hand, we haven't
+seen a specific alternative yet.
+
+> 2. Overload resolution. Randy proposed it should be "just like
+> aggregates", which means the expected type must be a "single type".
+> That means you have to stick in some qualifications where you
+> otherwise wouldn't have to. I agree with Randy on this.
+> I think Tucker does, too. You disagree. I don't think
+> JP said anything about this issue.
+>
+> Note that my opinion on (2) is based on readability, so your claims
+> that it's trivial to implement without the "single type" rule don't
+> sway me, even if they are true (which I doubt -- note that you'd have
+> to intersect an arbitrary number of types when you have elsif chains).
+
+I'm less comfortable with the "just like aggregates" rule in this case.
+
+Aggregates, in their full generality, are very complex and I think the
+single-expected-type name resolution for aggregates is completely appropriate.
+
+Integer literals, for example, are far less complex and that is why the language
+allows
+
+ procedure P (X : Integer) is ... ;
+ procedure P (X : Float) is ... ;
+ begin
+ P (2); -- legal
+
+Conditional expressions lie somewhere in the middle. The Access attribute is
+another such construct.
+
+When Ada95 was first introduced, any use of 'Access was required to have a
+single expected type. Practical experience showed that this restriction was
+annoying. The example given in AI95-00235 is
+
+ type Int_Ptr is access all Integer;
+ type Float_Ptr is access all Float;
+ function Zap (Val : Int_Ptr) return Float;
+ function Zap (Val : Float_Ptr) return Float;
+ Value : aliased Integer := 10;
+ Result1 : Float := Zap (Value'access); -- Legal?
+
+Before the AI, this example was illegal.
+It is generally agreed now (I think) that this was a mistake and that AI-235 was
+a good thing.
+
+It seems to me that we are contemplating making a similar mistake here.
+
+I also don't buy the argument that this would be terribly difficult to
+implement, but that's not really the main question we should be considering
+(unless someone wants to argue that the implementation difficulties are
+substantially more significant than anyone has suggested so far).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 1:50 PM
+
+> The parens in this example
+>
+> pragma Assert ((if A then B else C));
+>
+> look a bit odd, but we certainly don't want to allow
+>
+> begin
+> P (if A then B elsif C then D, if E then F elsif G then H else
+> I);
+
+why not? it's always possible to write things that look bad, that's not a
+sufficient reason for trying to outlaw them.
+
+> The problem is where to draw the line.
+
+let good taste draw the line
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 17, 2009 9:37 AM
+
+> One remaining question is whether un-parenthesized conditional
+> expressions would be permitted in some contexts, such as parameters in
+> a call, and other contexts where they would follow "=>", to avoid the
+> annoyance of double parentheses and the LISP-like appearance.
+
+I already indicated that I am in favor of allowing to leave off the "extra"
+parens in things like:
+
+ pragma Assert (if ...);
+
+But I don't feel strongly about it. Randy is opposed.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 2:40 PM
+
+I'm certainly in favor of leaving them out whenever possible, including the
+contexts Tuck mentions.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 17, 2009 3:57 PM
+
+> Intersecting types of candidate interpretations is the natural thing
+> to do in several places during resolution, so this just falls out from
+> existing machinery. The rule is simple to state as a name resolution
+> rule:
+>
+> if the else part is missing, the expected type of each expression, and
+> the expected type of the conditional expression itself, is Boolean
+> Otherwise the expected type of each expression is any type, and all
+> the expressions must resolve to the same type.
+
+I don't think that's the rule we want. You want the type from context to be
+passed down. It would make this example:
+
+ Put_Line (Integer'Image (Num_Errors) &
+ (if Num_Errors = 1 then "error detected." else "errors detected."));
+
+ambiguous.
+
+But I just realized that the "single type" rule Randy and I have been advocating
+also makes this ambiguous! Uh oh.
+
+> These things are homogeneous, unlike aggregates, and it's natural to
+> state the rule in terms of that uniformity.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 17, 2009 4:08 PM
+
+> I think what JP meant was that, as with the special case for
+> aggregates in qualified expressions, a qualified expression whose
+> operand is a conditional expression would not require double
+> parentheses.
+> Elsewhere, JP doesn't seem worried about double parentheses, though
+> some of us seem to disagree with him (mildly, it seems). I think we
+> would all agree that qualified expressions should not require double
+> parentheses if the operand is a conditional expression.
+
+It should be noted that the write-up that I circulated on Saturday says exactly
+what Jean-Pierre suggested. So he's just confirming my recommendation.
+
+The only case where I have any sympathy for Tucker's suggestion is in a pragma
+with exactly one argument. But I don't see the point of making the syntax of the
+language irregular for that one particular case. And requiring the paren makes
+it much easier for syntax error detector/correctors to tell the difference
+between an if statement and conditional expression - making it more likely that
+the error will be flagged at the right place.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 4:12 PM
+
+> I don't think that's the rule we want. You want the type from context
+> to be passed down.
+
+Of course, the expressions are resolved from the context, nobody ever thought
+otherwise (even though my last sentence did not make this explicit). is the
+following better:
+
+if the else part is missing, the expected type of each expression,
+and the expected type of the conditional expression itself, is
+Boolean Otherwise all the expressions must resolve to the type of
+the context.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 4:32 PM
+
+> But I just realized that the "single type" rule Randy and I have been
+> advocating also makes this ambiguous! Uh oh.
+
+OK, is that enough to convince you, or will you suddenly decide that it makes things more readinable to write
+
+ Put_Line (Integer'Image (Num_Errors) &
+ String'(if Num_Errors = 1 then "error detected." else "errors detected."));
+
+:-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 4:34 PM
+
+> And requiring
+> the paren makes it much easier for syntax error detector/correctors to
+> tell the difference between an if statement and conditional expression
+> - making it more likely that the error will be flagged at the right place.
+
+I think that's bogus, there will after all be parens in any case,
+
+the clean rule would be that you have to ALWAYS have a set of parens around a
+conditional expression, but you don't need to *add* an extra pair in a context
+where the parens are already there.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 4:59 PM
+
+> the clean rule would be that you have to ALWAYS have a set of parens
+> around a conditional expression, but you don't need to *add* an extra
+> pair in a context where the parens are already there.
+
+That doesn't sound very easy to define formally.
+
+I think we would want to introduce a syntactic category called, say,
+"parameter_expression" defined as:
+
+ parameter_expression ::= conditional_expression | expression
+
+Where conditional_expression doesn't have parentheses around it.
+
+"parameter_expression" would replace "expression" in certain contexts, and
+certainly in:
+
+ primary ::= (parameter_expression)
+
+But the intent would be for "parameter_expression" to replace "expression" in:
+
+ explicit_actual_parameter ::= parameter_expression | variable_name
+
+and in:
+
+ pragma_argument_association ::=
+ [pragma_argument_identifier =>] name
+ | [pragma_argument_identifier =>] parameter_expression
+
+and in:
+
+ discriminant_association ::=
+ [discriminant_selector_name
+ {| discriminant_selector_name} =>] parameter_expression
+
+and in the proposed aspect-specification clause
+
+ aspect_name [=> parameter_expression]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 4:48 PM
+
+> But I just realized that the "single type" rule Randy and I have been
+> advocating also makes this ambiguous! Uh oh.
+
+Perhaps we can say the following for the Name Resolution rules:
+
+ The expected type for each dependent expression is that of
+ the conditional expression as a whole. All dependent expressions
+ shall resolve to the same type. The type of the conditional
+ expression as a whole is this same type. If there is no ELSE part,
+ this type shall be a boolean type.
+
+This approach will ensure that the expected type has to be a suitable "single"
+type if any one of the dependent expressions requires a single type. For
+example, if one of the dependent expressions is a string literal, then the
+expected type has to be a single string type. We certainly don't want to have to
+start searching for all in-scope string types to resolve a conditional
+expression.
+
+I don't think Ed's "bottom-up" resolution rule would work very well in the
+presence of allocators, aggregates, string literals, etc.
+
+>> These things are homogeneous, unlike aggregates, and it's natural to
+>> state the rule in terms of that uniformity.
+
+But you have to be careful not to open up some formerly well-shuttered can of
+worms.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 5:01 PM
+
+> This approach will ensure that the expected type has to be a suitable
+> "single" type if any one of the dependent expressions requires a
+> single type. For example, if one of the dependent expressions is a
+> string literal, then the expected type has to be a single string type.
+> We certainly don't want to have to start searching for all in-scope
+> string types to resolve a conditional expression.
+
+This looks perfectly clear.
+
+> I don't think Ed's "bottom-up" resolution rule would work very well in
+> the presence of allocators, aggregates, string literals, etc.
+
+The resolution rules already work bottom-up with allocators, aggregates, and
+string literals (the candidate interpretations denote some class of types, for
+example any_access_type, or any_composite_type). Having these appear in a
+conditional expression changes nothing.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 17, 2009 5:23 PM
+
+> The resolution rules already work bottom-up with allocators,
+> aggregates, and string literals (the candidate interpretations denote
+> some class of types, for example any_access_type, or
+> any_composite_type). Having these appear in a conditional expression changes nothing.
+
+What I meant by "bottom-up" was that your earlier description made it sound like
+it required identifying specific types (as opposed to classes of types) in a
+bottom-up pass, using no context from above.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, March 17, 2009 8:20 PM
+
+What I meant is the standard two-pass resolution algorithm that no doubt we all
+use! We identify candidate interpretations bottom-up, and we find the single
+interpretation for a complete context top-down. I'm not proposing anything
+different: find interpretations of each expression, find the common
+intersection, and these are the candidate interpretations of the conditional
+expression as a whole. The full context will then indicate the expected type
+for it, and that gets propagated to each expression (which may have be
+overloaded).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 17, 2009 5:22 PM
+
+> That doesn't sound very easy to define formally.
+
+That per se is not a very strong argument. The point is that
+this rule does exactly what I think you want, and avoids
+bad uses. Your definition allows uses in other than contexts
+that meet the above rule, things like
+
+ X (if A then B else C, if D then Q else R)
+
+which I do not think is helpful. In fact I prefer to always
+have double parens rather than allow the above (yes, I know
+that this partially contradicts what I said before about
+allowing good taste to elimninate this case, but
+
+a) I had not thought of the rule above
+b) I diskliked this example more and more as I looked at it
+
+As for formal definition, either rely on adjunct english rather
+than write the syntax rules (after all our syntax for identifiers
+does not exclude reserved words, which would be a HUGE pain to
+do formally, though of course it could be done)
+
+or
+
+figure out the formal rules, and stick them in the grammar if
+it does not clutter things too much.
+
+By the way, if you go for the aspect notation, I would NOT
+exempt the single level of parens here. To me the only
+objectionable thing is explicitly having two parens before
+the if and two parens at the end of the expression. In any
+other context the parens are not just unobjectionable, they
+are desirable, given we do not have an ending "end if", we
+need for readability a clear consistent token to end the
+conditional expression and right paren is acceptable, but
+I don't like it being a comma soetimes, a semicolon sometimes
+etc.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, March 18, 2009 1:50 AM
+
+>> but we certainly don't want to allow
+>>
+>> begin
+>> P (if A then B elsif C then D, if E then F elsif G then H else
+>> I);
+>
+> why not? it's always possible to write things that look bad, that's
+> not a sufficient reason for trying to outlaw them.
+
+You could say the same for the rule (that I like a lot) that you can write "A
+and B and C" and "A or B or C", but not "A and B or C" without parentheses.
+
+I could go with something like this for if-expressions. Don't put parentheses in
+the syntax, but have a rule that if-expressions must be in parentheses if they
+appear:
+- as operand of a infix operator
+- as values of aggregates
+- other?
+
+This means that (if .. then ..) would appear as A_Parenthesized_Expression that
+contains An_If_Expression (that's -extended- ASIS-speak), but that the
+parentheses are required in some contexts. I think it is easier to define it
+this way than to define places where the parentheses are *not* required.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 18, 2009 7:22 AM
+
+This matches what I proposed with the notion of a "parameter_expression"
+syntactic category.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, March 18, 2009 9:04 AM
+
+Yes, I replied before seeing your mail. The difference is that I see it more as
+a legality rule than syntax - no big deal.
****************************************************************
Questions? Ask the ACAA Technical Agent