yield return based on Coroutines

[Robert Engels]

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. 

> On Aug 28, 2023, at 5:53 AM, Holo The Sage Wolf <holo3146 at gmail.com> wrote:
> 
> 
> Last time the conversation arise, the conversation revolved around the fact that virtual threads can replace all use cases of continuation.
> After quite a bit of back and forth, the conversation just died.
> 
> I'll try to find a link to the archive when I get home
> 
>> On Mon, Aug 28, 2023, 13:15 Daniel Schmid <daniel at wwwmaster.at> wrote:
>> Hi Rémi,
>> 
>> While this change may simplify the implementation, it would expose the Continuation to others (the Iterator can be accessed clients which could then access the Continuation with instanceof patternmatching or casting the Iterator).
>> While Continuation is an internal JVM class, I could imagine it becoming public API at some point (While it currently isn't, I don't know what would happen in the future) so I'd rather not use that approach unless required.
>> Because of that, these could then call Continuation.run bypassing the Iterator#hasNext/Iterator#next and it.
>> 
>> Besides, I don't see it being much simpler if the Iterator would extend Continuation as this would just result in passing the ContinuationScope and Runnable to the constructor of the iterator instead of the Continuation itself.
>> 
>> Yours,
>> Daniel
>> 
>> Am 28.08.2023 um 11:20 schrieb Remi Forax:
>>> Hi Daniel,
>>> I've taken a look to your implementation, i think it can be simpler,
>>> you can inherits from Continuation, so you can create a subclass of Continuation that implements Iterator with a field to store the yielded value.
>>> 
>>> Rémi
>>> 
>>> From: "Alan Bateman" <Alan.Bateman at oracle.com>
>>> To: "Daniel Schmid" <daniel at wwwmaster.at>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>, "jdk-dev" <jdk-dev at openjdk.org>
>>> Sent: Monday, August 28, 2023 11:12:51 AM
>>> Subject: Re: yield return based on Coroutines
>>> 
>>> This looks fun! It's probably best to bring this to loom-dev. In its archives you'll find several discussions about generators as several people have been interested in that topic. Even when thread confined, the main concern has been that exotic control flow yields leads to surprising behavior with many of the existing constructs, e.g. in your example think about behavior with finally blocks, try-with-resources, locks, ... when the iterator is not fully consumed.
>>> 
>>> -Alan
>>> 
>>> On 28/08/2023 09:43, Daniel Schmid wrote:
>>> Hi,
>>> 
>>> After seeing the JVM Language Summit talk on Continuations (https://www.youtube.com/watch?v=6nRS6UiN7X0), I thought about it being possible to implement something like "yield return" in languages like C# (or "yield" in Python) based on Continuations.
>>> Kotlin has implemented a similar feature as well: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/-sequence-scope/yield.html
>>> Now that Continuations are in the JDK, I feel like it can be used as a good primitive and now is a good time to start about thinking about adding something like this as a Java feature or the libraries.
>>> 
>>> After my experiments and some discussion with another developer named Peter Eastham (https://github.com/Crain-32), I was able to come up with an implementation/proof-of-concept allowing something like the following:
>>> 
>>> public static void main(String[] args) {
>>>     System.out.println("main thread: " + Thread.currentThread());
>>> 
>>>     for (String s : Yielder.create(YieldReturnTest::someMethod)) {
>>>         System.out.println("Text: " + s);
>>>     }
>>> }
>>> 
>>> private static void someMethod(Yielder<String> y) {
>>>     y.yield("Hello - " + Thread.currentThread());
>>>     System.out.println("between yields");
>>>     y.yield("World - " + Thread.currentThread());
>>> 
>>>     for (String s : Yielder.create(YieldReturnTest::otherMethod)) {
>>>         y.yield("nested: " + s);
>>>     }
>>> 
>>>     y.yield("bye - " + Thread.currentThread());
>>> }
>>> 
>>> private static void otherMethod(Yielder<String> y) {
>>>     y.yield("it can");
>>>     y.yield("also be");
>>>     y.yield("nested");
>>> }
>>> output:
>>> 
>>> main thread: Thread[#1,main,5,main]
>>> Text: Hello - Thread[#1,main,5,main]
>>> between yields
>>> Text: World - Thread[#1,main,5,main]
>>> Text: nested: it can
>>> Text: nested: also be
>>> Text: nested: nested
>>> Text: bye - Thread[#1,main,5,main]
>>> In this example, the method reference passed to the Yielder.create method would be run in a Continuation while y.yield would yield the Continuation and make the value available to the iterator (next() calls Continuation#run).
>>> 
>>> You can find a simple proof-of-concept of that here: https://github.com/danthe1st/ContinuationYieldReturn
>>> 
>>> Would it be possible to add something like this to the JDK libraries?
>>> I feel like it might be a useful addition to the JDK libraries as it simplifies creating sequences a lot.
>>> 
>>> Originally, I thought about whether it might be a good idea to add syntax for this but after building that proof-of-concept, it looks like it would be sufficient to add this to the libraries and using methods like this seems pretty natural.
>>> One thing I am concerned with this approach (opposed to an approach that involves changing syntax) is that it would be possible that the method suddenly runs in a different thread if the hasNext()/next()-calls of the Iterator chang the thread they are used in at some point. While Continuations allow this behaviour, it might seem a weird to developers who don't know how Continuations work.
>>> But aside from that issue with iterations switching threads, this approach seems pretty natural to me.
>>> 
>>> Yours,
>>> Daniel
>>> 
>>> 
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230828/c17b4ea5/attachment.htm>