extended membership tests

extended membership tests

[Dan]

Here's a fun quiz to test your Ada2012 knowledge, based on an
observation by Yannick Moy.

Consider this Ada 2012 procedure:

with ada.containers.ordered_sets;
procedure membership is
    package int_sets is new ada.containers.ordered_sets(integer);
    function "="(x,y: integer) return boolean is begin return true;
end;
    x: integer := 6;
    y: integer := 12;
    b1: boolean := x in y;
    b2: boolean := x in int_sets.to_set(new_item => y);
begin
    null;
end;

Which of the following are true:
  a)  b1 is true because 6 <= 12;
  b)  b1 is true because abs(6) <= abs(12);
  c)  b1 is true because 12 is an integer multiple of 6;
  d)  b1 is true because the binary representation of 6 appears in the
binary representation of 12;
  e)  b1 is true because x=y is true (using redefined "=");
  f)   b1 is false because x=y is false (using standard."=");
  g)  b2 is false because 6 is not in the set containing only the
number 12;
  h)  the program is illegal because of b1;
  i)   the program is illegal because of b2.

Re: extended membership tests

[AdaMagica]

On 31 Mrz., 09:04, Dan <d...@irvine.com> wrote:
> Here's a fun quiz to test your Ada2012 knowledge, based on an
> observation by Yannick Moy.
>
> Consider this Ada 2012 procedure:
>
> with ada.containers.ordered_sets;
> procedure membership is
>     package int_sets is new ada.containers.ordered_sets(integer);
>     function "="(x,y: integer) return boolean is begin return true;
> end;
>     x: integer := 6;
>     y: integer := 12;
>     b1: boolean := x in y;
>     b2: boolean := x in int_sets.to_set(new_item => y);
> begin
>     null;
> end;

My first reaction was WTF!

But RM 4.5.2 seems to make x in y legal, but false here.

x in y | 1..7

would be true.

b2 is illegal, the simple expression must be of an elementary type.

Hope this is correct.

Re: extended membership tests

[Dan]

On Mar 31, 12:34 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
> On 31 Mrz., 09:04, Dan <d...@irvine.com> wrote:
>
>
>
>
>
> > Here's a fun quiz to test your Ada2012 knowledge, based on an
> > observation by Yannick Moy.
>
> > Consider this Ada 2012 procedure:
>
> > with ada.containers.ordered_sets;
> > procedure membership is
> >     package int_sets is new ada.containers.ordered_sets(integer);
> >     function "="(x,y: integer) return boolean is begin return true;
> > end;
> >     x: integer := 6;
> >     y: integer := 12;
> >     b1: boolean := x in y;
> >     b2: boolean := x in int_sets.to_set(new_item => y);
> > begin
> >     null;
> > end;
>
> My first reaction was WTF!
>
> But RM 4.5.2 seems to make x in y legal, but false here.
>
> x in y | 1..7
>
> would be true.
>
> b2 is illegal, the simple expression must be of an elementary type.
>
> Hope this is correct.- Hide quoted text -
>
> - Show quoted text -

I think if the choice(s) resolve to the same type they don't have to
be elementary,
according to 4.5.2(3/3).  (other than that, good answer!)

Re: extended membership tests

[Dan]

On Mar 31, 12:55 am, Dan <d...@irvine.com> wrote:
> On Mar 31, 12:34 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
>
>
>
>
>
> > On 31 Mrz., 09:04, Dan <d...@irvine.com> wrote:
>
> > > Here's a fun quiz to test your Ada2012 knowledge, based on an
> > > observation by Yannick Moy.
>
> > > Consider this Ada 2012 procedure:
>
> > > with ada.containers.ordered_sets;
> > > procedure membership is
> > >     package int_sets is new ada.containers.ordered_sets(integer);
> > >     function "="(x,y: integer) return boolean is begin return true;
> > > end;
> > >     x: integer := 6;
> > >     y: integer := 12;
> > >     b1: boolean := x in y;
> > >     b2: boolean := x in int_sets.to_set(new_item => y);
> > > begin
> > >     null;
> > > end;
>
> > My first reaction was WTF!
>
> > But RM 4.5.2 seems to make x in y legal, but false here.
>
> > x in y | 1..7
>
> > would be true.
>
> > b2 is illegal, the simple expression must be of an elementary type.
>
> > Hope this is correct.- Hide quoted text -
>
> > - Show quoted text -
>
> I think if the choice(s) resolve to the same type they don't have to
> be elementary,
> according to 4.5.2(3/3).  (other than that, good answer!)- Hide quoted text -
>
> - Show quoted text -

but you are right, they don't the lhs doesn't resolve to the same type
as the rhs,
so in this case the rhs does need to be elementary.

Re: extended membership tests

[Ludovic Brenta]

Dan wrote:
> Here's a fun quiz to test your Ada2012 knowledge, based on an
> observation by Yannick Moy.
>
> Consider this Ada 2012 procedure:
>
> with ada.containers.ordered_sets;
> procedure membership is
>     package int_sets is new ada.containers.ordered_sets(integer);
>     function "="(x,y: integer) return boolean is begin return true;
> end;
>     x: integer := 6;
>     y: integer := 12;
>     b1: boolean := x in y;
>     b2: boolean := x in int_sets.to_set(new_item => y);
> begin
>     null;
> end;
>
> Which of the following are true:
>   a)  b1 is true because 6 <= 12;
>   b)  b1 is true because abs(6) <= abs(12);
>   c)  b1 is true because 12 is an integer multiple of 6;
>   d)  b1 is true because the binary representation of 6 appears in the
> binary representation of 12;
>   e)  b1 is true because x=y is true (using redefined "=");
>   f)   b1 is false because x=y is false (using standard."=");
>   g)  b2 is false because 6 is not in the set containing only the
> number 12;
>   h)  the program is illegal because of b1;
>   i)   the program is illegal because of b2.

Nice quiz... I'll post my answers later, to allow others to think some
more about it... or maybe all interested people should reply to you
privately? would you publish the results later? :)

--
Ludovic Brenta.

Re: extended membership tests

[AdaMagica]

>     package int_sets is new ada.containers.ordered_sets(integer);
>     x: integer := 6;
>     b2: boolean := x in int_sets.to_set(new_item => y);

Ah, my previous statement was not quite correct.
I didn't check, but I guess, sets are tagged, so the tested type is
tagged. Therefore the simple expression (x) must be convertible to the
tested type, which it isn't.
So the statement is illegal (as before, but for a different reason).

Re: extended membership tests

[Robert A Duff]

Dan <dan@irvine.com> writes:

> Here's a fun quiz to test your Ada2012 knowledge, based on an
> observation by Yannick Moy.

I won't answer, because I was involved in the discussion with Yannick.

> Consider this Ada 2012 procedure:
>
> with ada.containers.ordered_sets;
> procedure membership is
>     package int_sets is new ada.containers.ordered_sets(integer);
>     function "="(x,y: integer) return boolean is begin return true;
> end;
>     x: integer := 6;
>     y: integer := 12;
>     b1: boolean := x in y;
>     b2: boolean := x in int_sets.to_set(new_item => y);
> begin
>     null;
> end;

For extra credit, what happens if we replace b2 with:

    b3: boolean := int_sets.to_set(new_item => x)
                in int_sets.to_set(new_item => x)
                or int_sets.to_set(new_item => y);

;-)

- Bob

Re: extended membership tests (branch)

[Georg Bauhaus]

On 31.03.11 16:33, Robert A Duff wrote:
> Dan <dan@irvine.com> writes:
> 
>> Here's a fun quiz to test your Ada2012 knowledge, based on an
>> observation by Yannick Moy.
> 
> I won't answer, because I was involved in the discussion with Yannick.

I can't answer, but started wondering how this will
have to be interpreted:

    for b in b1 in b1 .. b1 loop
        null;
    end loop;

Re: extended membership tests (branch)

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> I can't answer, but started wondering how this will
> have to be interpreted:
>
>     for b in b1 in b1 .. b1 loop
>         null;
>     end loop;

That's a syntax error:

gnatmake -gnat2012 -gnatl eg.adb 
gcc -c -gnat2012 -gnatl eg.adb

GNAT Pro 6.5.0w (20110326)
Copyright 1992-2011, Free Software Foundation, Inc.


Compiling: eg.adb (source file time stamp: 2011-03-31 17:55:10)

     1. procedure Eg is
     2. begin
     3.    for B in B1 in B1 .. B1 loop
                      |
        >>> missing "loop"

     4.       null;
     5.    end loop;
     6. end Eg;

 6 lines: 1 error
gnatmake: "eg.adb" compilation error

- Bob

Re: extended membership tests (branch)

[Adam Beneschan]

On Mar 31, 9:28 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 31.03.11 16:33, Robert A Duff wrote:
>
> > Dan <d...@irvine.com> writes:
>
> >> Here's a fun quiz to test your Ada2012 knowledge, based on an
> >> observation by Yannick Moy.
>
> > I won't answer, because I was involved in the discussion with Yannick.
>
> I can't answer, but started wondering how this will
> have to be interpreted:
>
>     for b in b1 in b1 .. b1 loop
>         null;
>     end loop;

See AARM 3.5(3.a).  "for b in" has to be followed by either a subtype
name, a 'Range attribute, or two "simple expressions" with .. between
them.  In the last case, the bounds must be "simple expressions", not
general expressions.  The syntax of simple_expressions doesn't allow
membership tests (except in parentheses).  So the above is illegal.
This rule has been there since Ada 95.

                                 -- Adam

Re: extended membership tests (branch)

[Georg Bauhaus]

On 3/31/11 8:54 PM, Adam Beneschan wrote:

>>      for b in b1 in b1 .. b1 loop
>>          null;
>>      end loop;
>
> See AARM 3.5(3.a).  "for b in" has to be followed by either a subtype
> name, a 'Range attribute, or two "simple expressions" with .. between
> them.  In the last case, the bounds must be "simple expressions", not
> general expressions.  The syntax of simple_expressions doesn't allow
> membership tests (except in parentheses).  So the above is illegal.
> This rule has been there since Ada 95.

Thank you.  Now I have one more reason to like parentheses
around Boolean expressions outside conditionals. :-)

Re: extended membership tests (branch)

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:247eef65-9ff3-4268-af73-e74d092c1e82@k10g2000prh.googlegroups.com...
On Mar 31, 9:28 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
>> for b in b1 in b1 .. b1 loop
>> null;
>> end loop;
>
>See AARM 3.5(3.a).  "for b in" has to be followed by either a subtype
>name, a 'Range attribute, or two "simple expressions" with .. between
>them.  In the last case, the bounds must be "simple expressions", not
>general expressions.  The syntax of simple_expressions doesn't allow
>membership tests (except in parentheses).  So the above is illegal.
>This rule has been there since Ada 95.

Right. The only incompatibility involved with this new feature is with case 
statements. A membership test now needs to be parenthesized, as it did in 
Ada 83, but Ada 95 and Ada 2005 allowed it not to be in parens.

   when X in Y => -- Illegal in Ada 83 and Ada 2012, legal in Ada 95 and Ada 
2005.
   when (X in Y) => -- OK everywhere.

The reason is that something like:
   when X in Y | Z =>
would be ambiguous without the parens.

Beyond that, the likelyhood of writing something like this is pretty small 
anyway (why write a case statement on type Boolean??).

                             Randy.


                                 -- Adam 

Re: extended membership tests

[AdaMagica]

On 31 Mrz., 16:33, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> For extra credit, what happens if we replace b2 with:
>
>     b3: boolean := int_sets.to_set(new_item => x)
>                 in int_sets.to_set(new_item => x)
>                 or int_sets.to_set(new_item => y);

OK, I'll try. We should write this as

   b3: boolean :=
   int_sets.to_set(new_item => x) in
      int_sets.to_set(new_item => x) or int_sets.to_set(new_item =>
y);

So the right-hand side is a choice_expression of the form
simple_expression or simple_expression.
So if there isn't an or operator for sets (I don't know, I didn't
check the set container), it's illegal.
If there is one, it's a set (presumably the union) and it's the
tested_set.
The lhs is a simple_expression which is tagged (I presume sets are
tagged) which must resolve to a type convertible to the tested type,
which it is.
Now we have an individual membership test lhs in rhs.
The simple expression (lhs) is not equal to the value of the
membership_choice (rhs). So the membership test returns False.

   int_sets.to_set(new_item => x) in
      int_sets.to_set(new_item => x) | int_sets.to_set(new_item => y);

would return True.

This doesn't seem very intuitive to me. (Provided that my reading of
the RM is correct.)

Re: extended membership tests

[Dan]

On Mar 31, 10:14 pm, AdaMagica <christ-usch.gr...@t-online.de> wrote:
> On 31 Mrz., 16:33, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> > For extra credit, what happens if we replace b2 with:
>
> >     b3: boolean := int_sets.to_set(new_item => x)
> >                 in int_sets.to_set(new_item => x)
> >                 or int_sets.to_set(new_item => y);
>
> OK, I'll try. We should write this as
>
>    b3: boolean :=
>    int_sets.to_set(new_item => x) in
>       int_sets.to_set(new_item => x) or int_sets.to_set(new_item =>
> y);
>
> So the right-hand side is a choice_expression of the form
> simple_expression or simple_expression.
> So if there isn't an or operator for sets (I don't know, I didn't
> check the set container), it's illegal.
> If there is one, it's a set (presumably the union) and it's the
> tested_set.
> The lhs is a simple_expression which is tagged (I presume sets are
> tagged) which must resolve to a type convertible to the tested type,
> which it is.
> Now we have an individual membership test lhs in rhs.
> The simple expression (lhs) is not equal to the value of the
> membership_choice (rhs). So the membership test returns False.
>
>    int_sets.to_set(new_item => x) in
>       int_sets.to_set(new_item => x) | int_sets.to_set(new_item => y);
>
> would return True.
>
> This doesn't seem very intuitive to me. (Provided that my reading of
> the RM is correct.)

I think it's fair to say that the proposed definition of the
membership operator to
sometimes mean "=" is counter-intuitive to just about everyone, and is
an unintended
consequence of the new syntax rules which were designed for more
complicated expressions,
such as x in 2 | 5..10.

I think it's also somewhat likely that the language will be extended
at some point to
allow the membership operator to apply to the Set containers, or
actually any "iterable" type.
AI05-0139-2 proposes to integrate iterable types with for loops, and
it would seem to be
a natural extension to similarly integrate them with membership
tests.  But if that is done,
the possible interpretation of X in Y as an equality test would be
even more confusing than
it is now (as the b3 example suggests).

Yannick suggested making X in Y illegal, when X and Y have the same
type, to avoid the
confusion.  I agree with that suggestion.

         -- Dan

Re: extended membership tests

[AdaMagica]

On 1 Apr., 08:33, Dan <d...@irvine.com> wrote:
> Yannick suggested making X in Y illegal, when X and Y have the same
> type, to avoid the
> confusion.  I agree with that suggestion.

I also agree.

I do not see why we need choice_expression and choice_relation RM
4.4(2.1/3,2.2/3).
Wouldn't simple_expression suffice in (3.2/3)?

membership_choice ::= simple_expression | range | subtype_mark

Are there any sensible uses for (boolean) choice_relations? I might
imagine some use of choice_expressions for modular types.

X in A > B and C | D .. E | Subrange  ??? doesn't look very sensible
to me

Examples please.

Re: extended membership tests

[stefan-lucks]

On Fri, 1 Apr 2011, AdaMagica wrote:

> Are there any sensible uses for (boolean) choice_relations? I might
> imagine some use of choice_expressions for modular types.

genecic
  type T is <>;
procedure P(...);

-- Inside P, there may be some sensible uses for choice relations. 

procedure Q is new P(Boolean);



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: extended membership tests

[Adam Beneschan]

On Apr 1, 12:03 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
> On 1 Apr., 08:33, Dan <d...@irvine.com> wrote:
>
> > Yannick suggested making X in Y illegal, when X and Y have the same
> > type, to avoid the
> > confusion.  I agree with that suggestion.
>
> I also agree.
>
> I do not see why we need choice_expression and choice_relation RM
> 4.4(2.1/3,2.2/3).
> Wouldn't simple_expression suffice in (3.2/3)?

That could lead to ambiguous expressions like "X in Y in Z".  I
suppose the authors could have just used simple_expression and then
made a rule to prevent ambiguous expressions like the above, but doing
it by creating a new BNF rules as they did makes things more rigorous.


> membership_choice ::= simple_expression | range | subtype_mark
>
> Are there any sensible uses for (boolean) choice_relations?
> I might
> imagine some use of choice_expressions for modular types.
>
> X in A > B and C | D .. E | Subrange  ??? doesn't look very sensible
> to me
>
> Examples please.

You may be right that there aren't many "uses" of choice_relations,
but that wasn't the point.  The point was that this is just a way to
write syntax rules that defines an expression that doesn't allow
membership tests (except inside parentheses) but otherwise has all the
same rules as other expressions.  And I think that's how they intended
programmers to think about it.  Programmers shouldn't worry about the
distinction between a "relation" and a "choice_relation" any more than
they should worry about the difference between a "term" and a
"factor".

                                  -- Adam

Re: extended membership tests

[Randy Brukardt]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:0a58c4e0-f4b5-4cab-8aa7-7ab39337664e@p13g2000yqh.googlegroups.com...
...
>I do not see why we need choice_expression and choice_relation RM
>4.4(2.1/3,2.2/3).
>Wouldn't simple_expression suffice in (3.2/3)?

It exists so that the incompatibility with case statements is limited only 
to memberships. Without the choice_expression syntax,

    when A and 16#0100# =>

would be syntactically illegal. No one cares about Boolean case statements, 
but in this example A is a modular value, and it makes at least some sense 
to write this. As such we worried that it might actually exist in code (it's 
a common idiom in code that intefaces to Win32, for one example), and since 
the fix is relatively easy (a bit of additional syntax), we added the extra 
syntax. It's discussed in the e-mail filed in AI05-0158-1 (but not in the 
body of the AI itself).

                               Randy.