Coroutine for Swift

Evolution Discussion
1

here is my proposal for swift lang

https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md

2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com

···

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <swift-evolution@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:
[swift-evolution] Proposal: Add generator functions to the language

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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

with consider defer statement
we can clean up the memory if coroutine is not completed.

i have updated the proposal.

···

2015-12-22 15:33 GMT+08:00 Andrew Bennett <cacoyi@gmail.com>:

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:

[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

Hi, Andrew Bennett

I have updated the proposal with some of your suggestions.

Susan

···

---------- Forwarded message ----------
From: Susan Cheng <susan.doggie@gmail.com>
Date: 2015-12-22 16:19 GMT+08:00
Subject: Re: [swift-evolution] Coroutine for Swift
To: Andrew Bennett <cacoyi@gmail.com>

2015-12-22 15:33 GMT+08:00 Andrew Bennett <cacoyi@gmail.com>:

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:

[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

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@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com
<javascript:_e(%7B%7D,'cvml','daniel@upzzle.com');>

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@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:

[swift-evolution] Proposal: Add generator functions to the language

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@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

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@upzzle.com

···

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@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@upzzle.com <mailto:daniel@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com <javascript:_e(%7B%7D,'cvml','daniel@upzzle.com');>

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@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:
[swift-evolution] Proposal: Add generator functions to the language

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@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

9

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@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@upzzle.com
<javascript:_e(%7B%7D,'cvml','daniel@upzzle.com');>

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@gmail.com
<javascript:_e(%7B%7D,'cvml','susan.doggie@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@upzzle.com
<javascript:_e(%7B%7D,'cvml','daniel@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <
swift-evolution@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:

[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

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@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@upzzle.com <mailto:daniel@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@upzzle.com <javascript:_e(%7B%7D,'cvml','daniel@upzzle.com');>

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@gmail.com <javascript:_e(%7B%7D,'cvml','susan.doggie@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@upzzle.com <javascript:_e(%7B%7D,'cvml','daniel@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com <>

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <swift-evolution@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:
[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org <>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

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@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@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@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@upzzle.com

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@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@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <swift-evolution@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:
[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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@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@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@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@upzzle.com > <javascript:_e(%7B%7D,'cvml','daniel@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@upzzle.com

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@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@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <
swift-evolution@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:

[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

13

FWIW: GitHub - Zewo/Venice: Coroutines, structured concurrency and CSP for Swift on macOS and Linux.

···

On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution < swift-evolution@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@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@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@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@upzzle.com

El 22 des 2015, a les 11:50, Susan Cheng <susan.doggie@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@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:

A Tour of Go
A Tour of Go
A Tour of Go
https://youtu.be/f6kdp27TYZs

What you think?

Daniel

Daniel Valls Estella · tel. 659.910.830 · daniel@upzzle.com

El 22 des 2015, a les 8:33, Andrew Bennett via swift-evolution <
swift-evolution@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:

[swift-evolution] Proposal: Add generator functions to the language

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

I guess you prefer a cross-platform coroutine library that wrote by Swift.

Here is my implement of Swift Coroutine which base on boostorg/context.

It's API style(structured concurrency and CSP) inspired by kotlinx.coroutines.

Support Platform:

  • android
  • macOS
  • windows10
  • iOS
  • unbuntu

Usage(base on GCD) for peek:

func example_06() throws {
    // Example-06
    // ===================
    print("Example-06 =============================")

    let queue = DispatchQueue.global()
    let queue_001 = DispatchQueue(label: "queue_001", attributes: .concurrent)
    let queue_002 = DispatchQueue(label: "queue_002", attributes: .concurrent)

    queue.async {
        Thread.sleep(forTimeInterval: 0.005)
        print("other job \(Thread.current)")
    }

    let coJob1 = CoLauncher.launch(name: "co1", dispatchQueue: queue) { (co: Coroutine) throws -> String in
        defer {
            print("co 01 - end \(Thread.current)")
        }
        print("co 01 - start \(Thread.current)")
        try co.continueOn(queue_001)
        print("co 01 - continueOn - queue_001 -  \(Thread.current)")
        try co.continueOn(DispatchQueue.main)
        print("co 01 - continueOn - queue_main -  \(Thread.current)")
        try co.continueOn(queue_002)
        print("co 01 - continueOn - queue_002 -  \(Thread.current)")
        try co.continueOn(queue)

        return "co1 's result"
    }

    try coJob1.join()

    Thread.sleep(forTimeInterval: 1)
}

continueOn is API for switching threads.

If you are a server-side developer, maybe Swift_Coroutine_NIO2 more prefer.