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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Simon Wright" <[email protected]> wrote in message news:[email protected]...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Randy Brukardt" <[email protected]> writes:

"Simon Wright" <[email protected]> wrote in message news:[email protected]...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

"Randy Brukardt" <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <[email protected]d> writes:

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

"Randy Brukardt" <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Simon Wright" <[email protected]> wrote in message news:[email protected]...

Lawrence D'Oliveiro <[email protected]d> writes:

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

"Randy Brukardt" <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)