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