Reduction expressions

Reduction expressions

[Simon Wright]

Are the Accum_Type & Value_Type (ARM 4.5.10(9/5)) of a reduction attribute
reference required to be definite?

ARM 4.5.10(24/5) & (25.5) seem to imply so, which explains why GNAT
doesn't support e.g. String.

Re: Reduction expressions

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly5xs4d2ft.fsf@pushface.org...
> Are the Accum_Type & Value_Type (ARM 4.5.10(9/5)) of a reduction attribute
> reference required to be definite?
>
> ARM 4.5.10(24/5) & (25.5) seem to imply so, which explains why GNAT
> doesn't support e.g. String.

Accum_Subtype (we changed the name since it is a subtype, not a type; 
various clarifications were made to the wording as well in AI22-0011-1, 
AI22-0047-1, and AI22-0069-1) most likely has to be definite since the 
accumulator is of that type, and the bounds/constraints of the accumulator 
are thus defined by the initial value. In most uses, the first call on 
Reduce would then raise Constraint_Error (because the bounds/constraints are 
incorrect). I don't think there is any reason that the Value_Subtype has to 
be definite for a sequential reduce (a parallel reduce requires the two 
subtypes to statically match).

Note that if someone has a clever way to use an indefinite result, it is 
allowed. For instance, I could see a class-wide result making sense in some 
limited circumstances. But I don't think String would do anything useful, 
since the bounds are determined by the initial value.

BTW, this answer is essentially topic #1 of AI22-0011-1.

                    Randy.

Re: Reduction expressions

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:ly5xs4d2ft.fsf@pushface.org...
>> Are the Accum_Type & Value_Type (ARM 4.5.10(9/5)) of a reduction attribute
>> reference required to be definite?
>>
>> ARM 4.5.10(24/5) & (25.5) seem to imply so, which explains why GNAT
>> doesn't support e.g. String.
>
> Accum_Subtype (we changed the name since it is a subtype, not a type; 

Amazing how a person (I) can have used Ada for ~40 years and still be
hard put to it to describe the difference, at least in a case like this
one, where the ARG members clearly see meanings that leave me lukewarm
if not cold. Maybe "the heart of twilight"?

>           But I don't think String would do anything useful, 
> since the bounds are determined by the initial value.

String was just the simplest indefinite type for an example.

> BTW, this answer is essentially topic #1 of AI22-0011-1.

Thanks for the pointer.

Re: Reduction expressions

[Lawrence D'Oliveiro]

On Tue, 20 Aug 2024 22:23:27 +0100, Simon Wright wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Accum_Subtype (we changed the name since it is a subtype, not a type;
> 
> Amazing how a person (I) can have used Ada for ~40 years and still be
> hard put to it to describe the difference, at least in a case like this
> one, where the ARG members clearly see meanings that leave me lukewarm
> if not cold. Maybe "the heart of twilight"?

I thought the difference was obvious. “subtype” is the C equivalent of 
“typedef”, just giving a new name to an existing type. So

    subtype A is B;

(where A and B are simple identifiers) is valid, whereas

    type A is B;

is not: a “type” declaration always creates a new type: you have to write 
at least

    type A is new B;

and now you have two types with different names that are structurally the 
same, but not compatible.

Re: Reduction expressions

[Keith Thompson]

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
> I thought the difference was obvious. “subtype” is the C equivalent of 
> “typedef”, just giving a new name to an existing type. So
>
>     subtype A is B;
>
> (where A and B are simple identifiers) is valid, whereas
>
>     type A is B;
>
> is not: a “type” declaration always creates a new type: you have to write 
> at least
>
>     type A is new B;
>
> and now you have two types with different names that are structurally the 
> same, but not compatible.

A subtype with no added constraint is similar to a C typedef, but given

    subtype Digit is Integer range 0..9;

Digit is distinct from Integer (though they're both the same type).

C doesn't have anything directly corresponding to Ada subtypes.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Re: Reduction expressions

[Lawrence D'Oliveiro]

On Tue, 20 Aug 2024 16:41:55 -0700, Keith Thompson wrote:

> A subtype with no added constraint is similar to a C typedef, but given
> 
>     subtype Digit is Integer range 0..9;
> 
> Digit is distinct from Integer (though they're both the same type).

“Integer range 0..9” is a subtype of Integer, and is valid for example as 
a return type where Integer is expected. The “subtype” declaration doesn’t 
actually create the subtype: “Digit” is just a shorthand name for that, 
just like a C typedef.

Re: Reduction expressions

[Simon Wright]

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 20 Aug 2024 22:23:27 +0100, Simon Wright wrote:
>
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> 
>>> Accum_Subtype (we changed the name since it is a subtype, not a type;
>> 
>> Amazing how a person (I) can have used Ada for ~40 years and still be
>> hard put to it to describe the difference, at least in a case like
>> this one, where the ARG members clearly see meanings that leave me
>> lukewarm if not cold. Maybe "the heart of twilight"?
>
> I thought the difference was obvious. “subtype” is the C equivalent of
> “typedef”, just giving a new name to an existing type. So
>
>     subtype A is B;
>
> (where A and B are simple identifiers) is valid, whereas
>
>     type A is B;
>
> is not: a “type” declaration always creates a new type: you have to
> write at least
>
>     type A is new B;
>
> and now you have two types with different names that are structurally
> the same, but not compatible.

Yes, I've understood that for a long time but ... ARM22 4.5.10(8,9)[1]
say

(8) The expected type for a reduction_attribute_reference shall be a
    single nonlimited type.

(9) In the remainder of this subclause, we will refer to nonlimited
    subtypes Value_Type and Accum_Type of a
    reduction_attribute_reference. ...

and in AI 22-0011-1 [2] starting at 22-Oct-2021 5:25 PM,

* SB: raises a series of observations,
* STT: "... You really need to think of Accum_Type as a particular
  *subtype*"
* SB: "Ok, I was confused - Accum_Type is a subtype, not a type. So
  a lot of my message was noise."

If SB can be confused, so can I!

[1] http://www.ada-auth.org/standards/22rm/html/RM-4-5-10.html#p8
[2] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai22s/ai22-0011-1.txt?rev=1.2

Re: Reduction expressions

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyfrqynwpm.fsf@pushface.org...
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Tue, 20 Aug 2024 22:23:27 +0100, Simon Wright wrote:
>>
>>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>>
>>>> Accum_Subtype (we changed the name since it is a subtype, not a type;
>>>
>>> Amazing how a person (I) can have used Ada for ~40 years and still be
>>> hard put to it to describe the difference, at least in a case like
>>> this one, where the ARG members clearly see meanings that leave me
>>> lukewarm if not cold. Maybe "the heart of twilight"?
>>
>> I thought the difference was obvious. "subtype" is the C equivalent of
>> "typedef", just giving a new name to an existing type. So
>>
>>     subtype A is B;
>>
>> (where A and B are simple identifiers) is valid, whereas
>>
>>     type A is B;
>>
>> is not: a "type" declaration always creates a new type: you have to
>> write at least
>>
>>     type A is new B;
>>
>> and now you have two types with different names that are structurally
>> the same, but not compatible.
>
> Yes, I've understood that for a long time but ... ARM22 4.5.10(8,9)[1]
> say
>
> (8) The expected type for a reduction_attribute_reference shall be a
>    single nonlimited type.
>
> (9) In the remainder of this subclause, we will refer to nonlimited
>    subtypes Value_Type and Accum_Type of a
>    reduction_attribute_reference. ...
>
> and in AI 22-0011-1 [2] starting at 22-Oct-2021 5:25 PM,
>
> * SB: raises a series of observations,
> * STT: "... You really need to think of Accum_Type as a particular
>  *subtype*"
> * SB: "Ok, I was confused - Accum_Type is a subtype, not a type. So
>  a lot of my message was noise."
>
> If SB can be confused, so can I!

Which is why we changed the name - if SB can be confused, it is a good bet 
that there is something wrong with the wording. That's why I usually 
recommend bleeding edge users use the bleeding edge RM - no point in 
rediscovering all of the bugs that we already know about. Unfortunately, in 
this case, I'm the only one that has the bleeding edge RM because I haven't 
finished adding all of the approved AIs to it. This group is some that I've 
done, which is why the answer to your question was relatively easy to find.

                                 Randy.