yield return based on Coroutines

[Daniel Schmid]

Should a JBS issue be created in order to track the effort of 
introducing generators?

Also, if a stream-based implementation is wanted, it would be possible 
to create another method returning a stream.
I have adapted my demo to illustrate that: 
https://github.com/danthe1st/ContinuationYieldReturn/

And I want to mention that the word "Coroutines" in the subject line was 
my fault/a typo since I wanted to write "based on Continuations".

Yours,
Daniel

Am 29.08.2023 um 16:39 schrieb Pedro Lamarão:
> Em seg., 28 de ago. de 2023 às 08:35, Robert Engels 
> <rengels at ix.netcom.com> escreveu:
>
>     I let it die :) - I thought because I proved that there was no
>     difference in syntax or implementation by using virtual threads
>     directly rather than requiring a new language continuation
>     construct. There was some minor disagreement left that a “language
>     continuation” could allow slightly more deterministic collection
>     but I believe that was dismissed as being no different than other
>     resource management in the JDK.
>
>
> There is a need for, at the very least, a platform library construct.
> The fundamental reason why we need Generator in the platform is 
> because Generator is most economically defined as a direct application 
> of Continuation.
> The basic structural Generator element requires no scheduler, no 
> scoped local value cache, no interrupted flag, and has generally 
> nothing to do with threading.
> It is a basic building block typically available on continuation-based 
> machines, architecturally very close to methods.
>
> This basic, structural, Generator, as far as my own experiments have 
> gone, requires only a design decision on how to link run/next and 
> return/yield: a public static method (as presented in an early Loom 
> talk) or an abstract base class protected method, or an injected 
> "yield consumer", or maybe an injected method handle, or something else.
> As usual, this choice will involve trade offs: public static methods 
> may be called in the wrong context and require validation, injecting a 
> yielder object increases memory footprint, abstract base classes are 
> undesirable for whatever reason etc.
> Certain platforms have opted for special language support for defining 
> generators because, generators being architecturally close to methods, 
> having language support for yield in generators is equivalent to 
> having language support for return in methods.
> But I suppose that, at this point, people have acquired an allergy for 
> language "yield" as a consequence of this madness about "coroutines" 
> and async/away that have been plaguing platforms all around the place.
> I personally don't think language support is strictly necessary as 
> long as the platform is properly optimized for a library based 
> alternative.
>
> With no prejudice to the discussion on closing generator based 
> streams, I think this kind of discussion is about Generator 
> applications, not the basic Generator element itself.
>
> -- 
> Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230904/13832cb6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230904/13832cb6/smime-0001.p7s>