[swift-evolution] Coroutine for Swift

Tue Dec 22 16:26:45 CST 2015

Chris, Susan,

fwiw, this looks pretty similar to how we have Iterators as extension on our Swift compiler: http://docs.elementscompiler.com/Silver/LanguageExtensions/Iterators/. Looking forward to (something like) this becoming part of official Swift — the more custom extensions we can get rid of, the better ;).

—marc

> On Dec 22, 2015, at 6:13 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <swift-evolution at swift.org> 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 <daniel at upzzle.com> 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 · daniel at upzzle.com
>> 
>>> El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie at gmail.com> 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 <daniel at upzzle.com> 於 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 · daniel at upzzle.com
>>> 
>>>> El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> 
>>>>  _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution