[swift-evolution] Coroutine for Swift

Tue Dec 22 23:01:19 CST 2015

FWIW: https://github.com/Zewo/Venice

On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution <
swift-evolution at swift.org> 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 <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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/f6839a92/attachment-0001.html>