From Newsgroup: comp.lang.ada

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"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.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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 */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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 --- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

"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.


--- Synchronet 3.20a-Linux NewsLink 1.114