<div dir="ltr"><div dir="ltr">Em qua., 5 de jul. de 2023 às 10:56, Paul Bjorkstrand <<a href="mailto:paul.bjorkstrand@gmail.com">paul.bjorkstrand@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>I will bring it back to the challenge I gave to those wanting generators, exposed continuations, or custom schedulers for virtual threads: show why it is needed!<br></div></div></div></blockquote><div><br></div><div>The main benefit of having generators is aligned to one of the most common highlights for using virtual threads:</div><div>representing control flow directly, instead of doing state machines.</div><div>In the virtual thread case, this is all about asynchronous I/O; in the generator case, this is all about complex data formats.</div><div>Today, in order to process complex data formats, you either parse and generate an object for the entire data in one go (like DOM), or you parse and generate a stream pushing elements to callbacks that require your user to maintain a state machine (like SAX), or returning elements by maintaining an internal state machine (like XMLReader).</div><div>Only with the last, reader-like, design, parsers are easily composable -- by doing higher level parsers that consume suppliers of elements from a lower level parser.</div><div>But debugging these is hard, for the very same reason that debugging state-mechine-style asynchronous I/O programs is hard -- one must somehow follow the state transitions manually.</div><div>With generators, reader-like parsers can be written in the subroutine-style with no loss of efficiency.</div></div><div><br></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>