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

***************************************************************