Sujet : Re: Reduction expressions
De : randy (at) *nospam* rrsoftware.com (Randy Brukardt)
Groupes : comp.lang.adaDate : 20. Aug 2024, 05:59:04
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <va149e$388rf$1@dont-email.me>
References : 1
User-Agent : Microsoft Outlook Express 6.00.2900.5931
"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.