yield return based on Coroutines

[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/20230829/5bbd7b35/attachment.htm>