Redefining "in" "operator"

Redefining "in" "operator"

[Alejandro R. Mosteo]

It just dawned on me that I could want to define an "in" function for a 
couple of my types, but this is not allowed.

I tried searching but the term is so general that I only find unrelated 
threads, so here it goes:

Are there special reasons not to allow something like that? I think "in" 
is not an operator in the Ada RM sense but now I'm curious why the 
special treatment.

It's merely to avoid subversion of the default behavior? Couldn't it 
only be allowed for couples of types where it doesn't apply?

Thanks,
Álex.

Re: Redefining "in" "operator"

[Jeffrey R. Carter]

On 02/05/2018 05:26 PM, Alejandro R. Mosteo wrote:
> 
> Are there special reasons not to allow something like that? I think "in" is not 
> an operator in the Ada RM sense but now I'm curious why the special treatment.

The right side of "[not] in" is a subtype. Ada does not allow operators to have 
operands that are subtypes.

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: Redefining "in" "operator"

[J-P. Rosen]

Le 05/02/2018 à 17:26, Alejandro R. Mosteo a écrit :
> Are there special reasons not to allow something like that? I think "in"
> is not an operator in the Ada RM sense but now I'm curious why the
> special treatment.
Yes, there is ;-)

"in" is not an operator (i.e. a function), it's directly in the syntax
(see 4.4). And the reason for that is that the RHS is a membership
choice list, not an expression: there is no way you could write a
function whose argument is, f.e. a subtype or a range.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Redefining "in" "operator"

[Dmitry A. Kazakov]

On 2018-02-05 17:26, Alejandro R. Mosteo wrote:

> Are there special reasons not to allow something like that? I think "in" 
> is not an operator in the Ada RM sense but now I'm curious why the 
> special treatment.

Because some arguments are not first class citizens.

> It's merely to avoid subversion of the default behavior? Couldn't it 
> only be allowed for couples of types where it doesn't apply?
That depends on which "in" need to become a normal function.

1. Type types: if X in T'Class then

2. Sets: if I in A'Range then

3. Indicator sets: for I in A'Range loop

Only #1 is very difficult. #2 and #3 require some mental efforts and 
willingness of ARG.

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

Re: Redefining "in" "operator"

[Alejandro R. Mosteo]

On 05/02/18 17:26, Alejandro R. Mosteo wrote:
> It just dawned on me that I could want to define an "in" function for a 
> couple of my types, but this is not allowed.
> 
> I tried searching but the term is so general that I only find unrelated 
> threads, so here it goes:
> 
> Are there special reasons not to allow something like that? I think "in" 
> is not an operator in the Ada RM sense but now I'm curious why the 
> special treatment.

I see now, thanks everybody for the quick answers!

Re: Redefining "in" "operator"

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:p5a1bq$f3v$1@dont-email.me...
> On 02/05/2018 05:26 PM, Alejandro R. Mosteo wrote:
>>
>> Are there special reasons not to allow something like that? I think "in" 
>> is not an operator in the Ada RM sense but now I'm curious why the 
>> special treatment.
>
> The right side of "[not] in" is a subtype. Ada does not allow operators to 
> have operands that are subtypes.

Well, Ada 2012 also allows it to be a (set) of expressions as well. But your 
basic point applies: there aren't any function parameters that are subtypes 
or that are sets of expressions. One could imagine allowing a pair of 
expressions, but that's just "=" (and "in" in fact uses user-defined "=" 
when necessary).

                                 Randy.

Re: Redefining "in" "operator"

[Jeffrey R. Carter]

On 02/06/2018 01:48 AM, Randy Brukardt wrote:
> 
> Well, Ada 2012 also allows it to be a (set) of expressions as well. But your
> basic point applies: there aren't any function parameters that are subtypes
> or that are sets of expressions. One could imagine allowing a pair of
> expressions, but that's just "=" (and "in" in fact uses user-defined "="
> when necessary).

Yes, sorry; thanks for the clarification. When I first learned "in", it was 
subtypes all the way down. Ada 95 added classes of tagged types, and Ada 12, as 
you noted, expanded it further. None of these can be an operand of an operator. 
But when faced with a question like this I sometimes revert to my original 
understanding.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42