Re: choice_expression

[Adam Beneschan <adam@irvine.com>]

On Monday, October 8, 2012 6:34:27 AM UTC-7, Maxim Reznik wrote:
> Hi, all
> 
> I wounder why Ada 2012 membership test syntax is so complicated?
> 
> membership_choice ::= choice_expression | ...
> 
> What for choice_expression is?
> 
> I doubt someone is able to interprete this Ada 2012 expression:
> 
> "False in False and False"

I doubt anyone sane would write this expression, so this probably isn't a problem.  :)

> BTW GNAT understands it as "(False in False) and False"

If this isn't a typo, then GNAT is wrong; "and" has a higher precedence than "in", so that A in B and C should be intepreted as A in (B and C).


> Then, when you start adding '<', '|' expression became even more complicated:
> 
> For example 
>  "False in False and False | True" 
> 
> interpreted as
> 
>  "False in (False and False) | True"
> 
> I mean allowing relational and ligical operators in choice_expression makes syntax unclear, ambiguous and error-prone.
> 
> Why not just  
> 
> membership_choice ::= simple_expression | ...
> 
> and force user to write brackets around expression?

I personally can't imagine using a construct "X in ..." where X is a boolean expression.  It seems highly useless, except perhaps "X in A'Range" if A is an array declared with a "boolean range <>" index type, but that itself should hardly ever be needed.  So perhaps that's why it wasn't considered necessary to design special rules for this situation.  (On the other hand, some of the issues involving "and [then]" and "or [else]" that led the language designers to require parentheses *do* come up in real life, in other languages.)

                           -- Adam