Re: Reduction expressions

["Randy Brukardt" <randy@rrsoftware.com>]

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