FWIW: https://github.com/Zewo/Venice
On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution < [email protected]> wrote: > Hi, > > I just want a wide public concern in swift community with this > implementation. > Should we have a proposal about @goto and @label as workaround? Just a > joke ;) > > > Chris Lattner <[email protected]> 於 2015年12月23日星期三 寫道： > >> Hi Susan, >> >> 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. >> >> -Chris >> >> On Dec 22, 2015, at 12:16 PM, Andrew Bennett via swift-evolution < >> [email protected]> wrote: >> >> Hi Daniel, >> >> I've heard many great things about goroutines, and I definitively think >> their advantages should be considered in the design of Swift's concurrency. >> >> 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. >> >> The generator described in the proposal has the following properties: >> * it is basically just syntactic sugar >> * new elements are generated lazily >> * the length doesn't need to be known at initialisation >> * it uses existing function syntax in the caller >> * it can all run on one thread >> * concurrency considerations may be limited to safely updating the state >> variable from more than one thread >> >> 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. >> >> >> On Wednesday, 23 December 2015, Daniel Valls Estella <[email protected]> >> wrote: >> >>> >>> Ok, >>> >>> 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. >>> >>> Thanks for your answer! >>> >>> Daniel >>> >>> Daniel Valls Estella · tel. 659.910.830 · [email protected] >>> >>> El 22 des 2015, a les 11:50, Susan Cheng <[email protected]> va >>> escriure: >>> >>> It's a little difference with goroutine. Go using threads and signal. >>> My implementation is following C# methods that MS staff tells me. >>> >>> Daniel Valls Estella <[email protected]> 於 2015年12月22日星期二 寫道： >>> >>>> I think it’s better to take as a reference the *Go* language and his >>>> *goroutines* and *channels*. >>>> >>>> Not just to face these type of problems but also to take new >>>> architectural aproches to build software solutions. >>>> >>>> >>>> refs: >>>> >>>> https://tour.golang.org/concurrency/1 >>>> https://tour.golang.org/concurrency/2 >>>> https://tour.golang.org/concurrency/5 >>>> https://youtu.be/f6kdp27TYZs >>>> >>>> >>>> What you think? >>>> >>>> Daniel >>>> >>>> Daniel Valls Estella · tel. 659.910.830 · [email protected] >>>> >>>> El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution < >>>> [email protected]> va escriure: >>>> >>>> Great proposal! I'm all for this, I think your proposed implementation >>>> is pretty good too. >>>> >>>> It would be interesting to expand the proposal to consider more cases >>>> in more detail: >>>> * Concurrency >>>> * SequenceType versus GeneratorType >>>> * Should a language feature depend on the Standard Library >>>> (GeneratorType)? Alternatives: >>>> + func myFunction -> () -> T? >>>> + func myFunction -> () -> (myFunction_State, myFunction_State -> >>>> T?) >>>> * What happens if you write: guard ... else { yield ... } >>>> * Use an enum for the state that encapsulates all possible variables >>>> in each state >>>> >>>> If you're not familiar with it, there's another thread that discussed >>>> similar here: >>>> >>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001872.html >>>> >>>> In particular you may be interested in Chris Lattner's comment: >>>> >>>> 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). >>>> >>>> >>>> Either way it's worth discussing and working towards :) >>>> >>>> On Tue, Dec 22, 2015 at 6:03 PM, Félix Cloutier < >>>> [email protected]> wrote: >>>> >>>>> 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++. >>>>> >>>>> Generators are one use case, but resumable functions in general can >>>>> also be used to make async code look prettier. >>>>> >>>>> Félix >>>>> >>>>> Le 22 déc. 2015 à 01:47:05, Susan Cheng via swift-evolution < >>>>> [email protected]> a écrit : >>>>> >>>>> here is my proposal for swift lang >>>>> >>>>> >>>>> https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> >>>> >>> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
