choice_expression

choice_expression

[Maxim Reznik]

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"

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

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?

Re: choice_expression

[Adam Beneschan]

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

Re: choice_expression

[Maxim Reznik]

понедельник, 8 октября 2012 г., 17:49:05 UTC+3 пользователь Adam Beneschan написал:
> On Monday, October 8, 2012 6:34:27 AM UTC-7, Maxim Reznik wrote:
> 
> > 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).
> 

I belive priority of membership test is the same as for relational_operator, because both of them are in the same syntax rule, so interpretation should be the same as for "A < B and C" => "(A<B) and C". This equals to GNAT's one.

But force user to guess operator precedence is not good. Ada 83 avoided it long ago and I don't understand why Ada 2012 does it in other way even by complicated syntax.


> 
> I personally can't imagine using a construct "X in ..." where X is a boolean expression.  It seems highly useless, 
[skipped]

Neither I can't.

It looks strange why language designers added couple of dedicated ARM rules to allow useless constructs with unclear, ambiguous and error-prone syntax :(

Re: choice_expression

[Adam Beneschan]

On Monday, October 8, 2012 8:44:11 AM UTC-7, Maxim Reznik wrote:
> понедельник, 8 октября 2012 г., 17:49:05 UTC+3 пользователь Adam Beneschan написал:
> 
> > On Monday, October 8, 2012 6:34:27 AM UTC-7, Maxim Reznik wrote:
> 
> > > 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).

> I belive priority of membership test is the same as for relational_operator, because both of them are in the same syntax rule, so interpretation should be the same as for "A < B and C" => "(A<B) and C". This equals to GNAT's one.

Actually, there's nothing in the RM that says anything about the precedence of the membership test.  4.5(1-7) is the only place that clearly defines when two different operators have the same precedence, and "in" isn't listed at all.  So, on closer reading, I think the expression is ambiguous, and the language rules need to be fixed.  So my previous post was wrong.  If the expression had been confusing but unambiguous, I wouldn't have suggested any language change because it would have been too obscure to matter--it would involve only code that no sane person would actually write.  But since it's ambiguous, I think it needs to be addressed.


> But force user to guess operator precedence is not good. Ada 83 avoided it long ago

Not really.  Ada 83 fixed the precedence problem with "or" and "and", but a user still has to know what the precedence is in other cases.  In most instances, it's the same as in other languages, so a user familiar with other languages but new to Ada should still be able to figure it out.  But here's a case (no less obscure than the examples you're providing) that isn't obvious:

   A and B in SOMETHING

where A and B are Booleans and SOMETHING is a subtype of Boolean or something like Array'Range where the array index type is Boolean.  Is this 

   (A and B) in SOMETHING

or

   A and (B in SOMETHING) ?

I had to look that one up and study the syntax.  (It's the second one.)  But it's incorrect to say that Ada 83 avoided the problem of users having to guess precedence.

                     -- Adam

Re: choice_expression

[Dmitry A. Kazakov]

On Mon, 8 Oct 2012 10:01:46 -0700 (PDT), Adam Beneschan wrote:

> But
> here's a case (no less obscure than the examples you're providing) that
> isn't obvious:
> 
>    A and B in SOMETHING
> 
> where A and B are Booleans and SOMETHING is a subtype of Boolean or
> something like Array'Range where the array index type is Boolean.  Is this 
> 
>    (A and B) in SOMETHING
> 
> or
> 
>    A and (B in SOMETHING) ?

   not A in B

may mean either

   (not A) in B

 or

   not (A in B)  -- I think this is what Ada syntax does

Lattice operations are ambiguous. In mathematics they use different
notation for the operations Ada conflates. E.g. logical V vs. union U (like
in modular types). Both are denoted as "or" in Ada. It also uses | for U in
other cases. The membership test is conflated with the subset test and with
the subsumption test. All are just "in."

This might impose problems once ranges and tests become proper operations.

> But it's incorrect to say that Ada 83 avoided the problem of users having
> to guess precedence.

Ada found a way to solve the problem.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: choice_expression

[Randy Brukardt]

"Maxim Reznik" <reznikmm@gmail.com> wrote in message 
news:8ca46b0e-355e-4f77-a727-5c4846f98474@googlegroups.com...
???????????, 8 ??????? 2012 ?., 17:49:05 UTC+3 ???????????? Adam Beneschan 
???????:
> On Monday, October 8, 2012 6:34:27 AM UTC-7, Maxim Reznik wrote:
...
>> I personally can't imagine using a construct "X in ..." where X is a 
>> boolean expression.  It seems highly useless,
>[skipped]
>
>Neither I can't.
>
>It looks strange why language designers added couple of dedicated ARM rules 
>to
>allow useless constructs with unclear, ambiguous and error-prone syntax :(

We added the dedicated ARM rules to minimize incompatiblity with case 
statements and variant records(*). We used it in membership because we 
wanted those to work the same as case statements and variants records. No 
one noticed that it makes the grammar ambiguous, so thanks for pointing that 
out. It will be fixed.

                                          Randy.

(*) The grammar for a case choice changes from "expression" to 
"choice_expression" in Ada 2012. This means that using a membership without 
parens is now illegal in a case choice:

                 when X in Something =>

but that should almost never happen. OTOH, if we had used 
"simple_expression", then

                 when X and Bit_Mask =>

would be illegal (needing parens). If X has a modular type, this could come 
up (it definitely could in writing Windows bindings, for instance). Ada 95 
changed the grammar from "simple_expression" to "expression" for this 
reason, and thus it was uncomfortable to change this.