<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Should a JBS issue be created in order to track the effort of
introducing generators?</p>
<p>Also, if a stream-based implementation is wanted, it would be
possible to create another method returning a stream.<br>
I have adapted my demo to illustrate that: <a
moz-do-not-send="true"
href="https://github.com/danthe1st/ContinuationYieldReturn/"
class="moz-txt-link-freetext">https://github.com/danthe1st/ContinuationYieldReturn/</a><br>
</p>
<p>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".<br>
</p>
<p>Yours,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">Am 29.08.2023 um 16:39 schrieb Pedro
Lamarão:<br>
</div>
<blockquote type="cite"
cite="mid:CAC8PkgFAOUvTo6jwGDHRky6n+qo3fEM7vycc8n2DvWRF3EDKkA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Em seg., 28 de ago. de 2023 às 08:35, Robert
Engels <<a href="mailto:rengels@ix.netcom.com"
moz-do-not-send="true" class="moz-txt-link-freetext">rengels@ix.netcom.com</a>>
escreveu:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div dir="ltr">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. </div>
</div>
</blockquote>
<div><br>
</div>
<div>There is a need for, at the very least, a platform
library construct.</div>
<div>The fundamental reason why we need Generator in the
platform is because Generator is most economically defined
as a direct application of Continuation.
<div>The basic structural Generator element requires no
scheduler, no scoped local value cache, no
interrupted flag, and has generally nothing to do with
threading.<br>
</div>
<div>It is a basic building block typically available on
continuation-based machines, architecturally very close to
methods.</div>
<div><br>
<div>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.</div>
<div>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.<br>
</div>
<div>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.</div>
</div>
</div>
<div>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.</div>
<div>I personally don't think language support is strictly
necessary as long as the platform is properly optimized for
a library based alternative.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>Pedro Lamarão</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>