[swift-evolution] Coroutine for Swift

[Susan Cheng]

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 <clattner at apple.com> 於 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 <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/b8d3e6a8/attachment.html>