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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
