Version 1.1 of acs/ac-00308.txt
!standard 4.5.9(0) 18-12-14 AC95-00308/00
!class Amendment 18-12-03
!status received no action 18-12-03
!status received 18-10-19
!subject New Idea for coroutines
!summary
!appendix
From: Brad Moore
Sent: Friday, October 19, 2018 11:38 AM
I was thinking about the value_generator syntax suggested in the most recent
version of AI12-0262-1, and realized that it could also be used as the basis
for coroutines.
The idea here is that a value_generator could be applied as an aspect to a
type, the generator aspect, which would mean that subtype "has a generator".
Each variable of that subtype would have a generator attached.
Calling 'Next on that variable gets the next value from the generator, and
another attribute, 'Yielding, could be used to test whether the generator
has more values.
E.g.
The Prime mumber generator of the other versions of the AI could be
written as;
subtype Prime_Factory is Natural range 1 .. 1000
with Generator => [For I in Prime_Factory when Is_Prime (I) => I];
P : Prime_Factory;
while Not_Enough_Prime_Numbers loop
if P'Yielding then
Put_Line ("Next prime number is " & P'Next'Image);
end if;
end loop;
If we want to support an infinite generation of values, we could add an
infinite iteration to the value_generator definition, (which would not be
legal for the 'Reduce and 'Parallel_Reduce attributes), where the for
clause of the value_generator is replaced with the keyword, loop.
eg.
subtype Random_Number_Factory is Natural
with Generator => [loop => Random(Gen)];
R : Random_Number_Factory;
while Not_Enough_Random_Numbers loop
Put_Line ("Next random number is " & R'Next'Image);
end loop;
A nice feature of this approach is that there is no need for special syntax
in the implementation of the generator.
The Is_Prime function for example is just a regular function as it would be
written today.
This strikes me as a better alternative than the other 4 versions of the AI,
while at the same time, borrowing concepts from each.
Unless someone can poke some serious holes into the idea at least.
***************************************************************
From: Randy Brukardt
Sent: Friday, October 19, 2018 4:55 PM
...
> This strikes me as a better alternative than the other 4 versions of
> the AI, while at the same time, borrowing concepts from each.
> Unless someone can poke some serious holes into the idea at least.
One of the appeals of the generator idea is that some state can be saved
between calls to the generator, and that happens in a natural and mostly
automatic way. In this proposal, all of that state would have to be in the
iterator object, which we already know is hard to accomplish. (Indeed, I see
one of the reasons some people find this valuable is that they'd rather use a
generator than construct an iterator; you've essentially eliminated that
advantage by requiring an iterator if any state is needed.)
This doesn't seem to be a fatal flaw, but it's likely to reduce interest in
this version.
***************************************************************
Questions? Ask the ACAA Technical Agent