[swift-evolution] Coroutine for Swift

[Andrew Bennett]

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
> <javascript:_e(%7B%7D,'cvml','daniel at upzzle.com');>
>
> El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie at gmail.com
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/af47a27b/attachment.html>