<p dir="ltr">FWIW: <a href="https://github.com/Zewo/Venice">https://github.com/Zewo/Venice</a><br>
</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div><br></div><div>I just want a wide public concern in swift community with this implementation.</div><div>Should we have a proposal about @goto and @label as workaround? Just a joke ;)</div><div><br><div><br>Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> 於 2015年12月23日星期三 寫道：<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Susan,<div><br></div><div>As I mentioned on your original pull request, coroutines are closely related to async and other concurrency forms. That entire space is out of scope for Swift 3, so we should wait until fall 2016 to pick up discussion on this and related topics.</div><div><br></div><div>-Chris</div><div><br><div><blockquote type="cite"><div>On Dec 22, 2015, at 12:16 PM, Andrew Bennett via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Hi Daniel,</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">I've heard many great things about goroutines, and I definitively think their advantages should be considered in the design of Swift's concurrency.</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">I haven't used goroutines much so I may be incorrect, but I don't think they can be used to efficiently represent a generator like the proposal suggests.</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">The generator described in the proposal has the following properties:<br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * it is basically just syntactic sugar<br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * new elements are generated lazily</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * the length doesn't need to be known at initialisation</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * it uses existing function syntax in the caller</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * it can all run on one thread</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> * concurrency considerations may be limited to safely updating the state variable from more than one thread</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Maybe goroutines can be equivalent if the compiler can optimise it down to a generator. This proposal is basically syntactic sugar to concisely define a generator. Goroutines probably aren't a concise replacement for that sugar.</span></font></div><div><br></div></div><br>On Wednesday, 23 December 2015, Daniel Valls Estella <<a>daniel@upzzle.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div>Ok,</div><div><br></div><div>But I think goroutines are not really threads (are faster and cheaper enought to make a diference) and channels are more like filedescriptors than signals, you stream data throught these.</div><div><br></div><div>Thanks for your answer!</div><div><br></div><div>Daniel<br><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font size="3"><br></font></div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Daniel Valls Estella · tel. 659.910.830 · <a>daniel@upzzle.com</a></div>
</div>
<br><div><blockquote type="cite"><div>El 22 des 2015, a les 11:50, Susan Cheng <<a>susan.doggie@gmail.com</a>> va escriure:</div><br><div>It's a little difference with goroutine. Go using threads and signal.<div>My implementation is following C# methods that MS staff tells me.<br><br>Daniel Valls Estella <<a>daniel@upzzle.com</a>> 於 2015年12月22日星期二 寫道：<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I think it’s better to take as a reference the <b>Go</b> language and his <b>goroutines</b> and <b>channels</b>.<div><br></div><div>Not just to face these type of problems but also to take new architectural aproches to build software solutions.<br><div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font size="3"><br></font></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><font size="3" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px">refs:</font></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><font style="font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px"> </font></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><a href="https://tour.golang.org/concurrency/1" target="_blank">https://tour.golang.org/concurrency/1</a></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><a href="https://tour.golang.org/concurrency/2" target="_blank">https://tour.golang.org/concurrency/2</a></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><a href="https://tour.golang.org/concurrency/5" target="_blank">https://tour.golang.org/concurrency/5</a></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><a href="https://youtu.be/f6kdp27TYZs" target="_blank">https://youtu.be/f6kdp27TYZs</a></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><br></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><br></div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px">What you think?</div><div style="line-height:normal;text-align:-webkit-auto;text-indent:0px"><br></div><div style="font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Daniel</div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><font size="3"><br></font></div><div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Daniel Valls Estella · tel. 659.910.830 · <a>daniel@upzzle.com</a></div>
</div>
<br><div><blockquote type="cite"><div>El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <<a>swift-evolution@swift.org</a>> va escriure:</div><br><div><div dir="ltr"><div>Great proposal! I'm all for this, I think your proposed implementation is pretty good too.</div><div><br></div><div>It would be interesting to expand the proposal to consider more cases in more detail:</div><div> * Concurrency</div><div> * SequenceType versus GeneratorType<br></div><div> * Should a language feature depend on the Standard Library (GeneratorType)? Alternatives:<br></div><div> + func myFunction -> () -> T?</div><div> + func myFunction -> () -> (myFunction_State, myFunction_State -> T?)</div><div> * What happens if you write: guard ... else { yield ... }</div><div> * Use an enum for the state that encapsulates all possible variables in each state</div><div><br></div><div>If you're not familiar with it, there's another thread that discussed similar here:</div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001872.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001872.html</a><div><br></div><div>In particular you may be interested in Chris Lattner's comment:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">I’m very interested in this, but it is clearly out of scope for Swift 3. It should also be considered alongside whatever async/concurrency approach we tackle (likely in swift 4).</blockquote><br>Either way it's worth discussing and working towards :)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 22, 2015 at 6:03 PM, Félix Cloutier <span dir="ltr"><<a>swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>There's probably some additional work to do on the proposal document, but I would like to see coroutines in Swift too. The feature has been very successful in other languages like Python and C#, and unless I'm mistaken, work is being done to standardize it in C++.</div><div><br></div><div>Generators are one use case, but resumable functions in general can also be used to make async code look prettier.</div><br><div>
<span style="border-collapse:separate;line-height:normal;border-spacing:0px">Félix</span>
</div>
<br><div><blockquote type="cite"><span><div>Le 22 déc. 2015 à 01:47:05, Susan Cheng via swift-evolution <<a>swift-evolution@swift.org</a>> a écrit :</div><br></span><div><span><div dir="ltr"><div>here is my proposal for swift lang</div><div><br></div><a href="https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md" target="_blank">https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md</a><br></div>
</span><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k7cXv8i0D9519DoK7KYHAZzDNERxafB1pe872Yhhmi-2BiyWxsAHedNi3wh4t89fT-2BKwnNGjs9DnBFwV5eBmT6fDCjciSJZI8IeZaYr0UgGPnYQEVopgJV1xozCPgVx1QMsXTqwKj8GReKDgqgfrW75KolAqOxHlNELRYO4sMeFmSxsguQIkEf4l8dL3CnbhvjmU-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uRNKnTGhJeGxonM5msZE9opXco5hFz-2FepMTWpqOJKwxo-2Fe2VIVN6mVOrF-2BaySWURX-2BPZVsXp943zQJP31RiLgQHnpSgAtVY9mOb2RSUc-2FH4BhtUrKfWxse4Yvsyqr2k8wpDc9XBkOOssTr9lEtGPAkjmAzuM5b-2BPWpODXHOcg7J8BK9kuIMAJmyZbwiu-2BC5qAQ-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AdkfTiApI80cNEyortTzHW0kAjxqiRekfpEJArOEyyqmj4DRJx3ooJIHhV9lkZZFHQGuvpvgJ07djNDDr2cbO55ipOSLSgPiqKL6f2al0u374ShmXDyxxYjmu15DYu5LcQMApCVA087QaLw2hnsJZhbDN-2Fy7dLsjtWNZtEUOGpNGAv14a87mB3JmoluyGczE1totvhAJl6rgjxcY-2FGfKZZLIq6GDCiqz267BKWGvDbg-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RC5Cq0zAxCHc1sM9Uy3-2BojrrUAw-2F96zH69NULNHPvCu3zAKQCfMa3w2QykbEZu8idfPdMLbIXLbSm1b6SCR7vnJB-2FHiLxbYVFUNTgIlkKkM3cLfkVsdu775dpqiokFYnN8aQNwgZBP1kSDClAx1-2BYHEulvtaho9feEhs0Oz5afsf1Ykk-2BrLXPU8BPbJsMsuCqiWe7uzZLABmEgqZ-2B-2F5gCtvZAGzRkgn6px2Yhd45gRU-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=fuWmDRE6-2FDdvdUHeLHruUfdigJaxz7nh99l6HfkulY-2FX-2BCEX1g03vsVOwUYQSH2OwU3nZWp08j5q0deeRbkM2L2JsuzLCFBL768-2BM8jZjouNTuSt5GzIoySak4WLClvThhrMkUL9KlQ7i6mAKNtNhbAjRMjVm63GMmCLWZkUMOXE3mttnv3HQzExVDDKhsRbnJHSKm0cl8DOhhFlkCU3R0Oe95BIIKtV39y9pFb7KE8-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>