<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">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"></div><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>