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

[David Waite]

Because stackful coroutines quickly start to quickly approximate threading, I didn’t think they were appropriate to propose at this time. That said:

I think you would probably want something like Coroutine.create<String,()> so that the String->() and ()->String interfaces of the two objects can be generated. Likewise, in your example I believe a Coroutine-related protocol instance should be passed in that exposes a yield(value:String) -> () method 

Coroutines and generator functions both involve additional rules for cleanup. Imagine a coroutine or generator which walks a file or network stream, returning individual lines of text. The code using .resume() may stop reading once they recognize the line they need or encounter an error, but the system still needs to be able to reclaim the coroutine as well as close/reclaim the local/network stream resources.

The references need to be set up in such a way that objects are reclaimed in a predictable order, and defer blocks would probably be supported and run, to make such control flow more obvious. This compiler support which would be required whether you were doing (sequence) generator functions or “full” coroutines. In the generator case, such cleanup needs to be moved to the teardown of your state objects. It is possible some of the cleanup for full coroutines would be shared with pre-existing thread termination support.

Finally - any calls to yield might never resume, and it is possible your code will transition between processors/parent threads on the subsequent resume. This pushes me toward promoting a keyword vs using Coroutine.yield, and restricting use of the yield keyword to make such behavior more obvious (in the same way throws must be declared and try must be used when calling an error-throwing method today)

-DW

> On Dec 12, 2015, at 9:43 PM, Taras Zakharko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Personally, I am agains generators (its quite specific syntactic sugar that adds a lot of complexity), but I would be all for a comprehensive coroutine library*. One can model it after Lua’s coroutines (http://www.lua.org/pil/9.1.html <http://www.lua.org/pil/9.1.html>), which works well with the existing syntax. Your example becomes something like:
> 
> helloGenerator = Coroutine.create<()->String>({name:String -> () in 
>    Coroutine.yield(“Hello”)
>    Coroutine.yield(name ?? “World”)
> })
> 
> this generates a class instance with a resume ()->String? method that can be used to retrieve the values. You can also pass values via resume (they will be then available as results of coroutine.yield)
> 
> One can than use helloGenerator.resume() to get the values (which can be easily wrapped in a sequence etc).
> 
> Benefits of this approach: no need for significant syntactic change (although a coroutine keyword could be introduced instead of func to wrap the above declaration), the coroutine functions are offloaded to a type rather than syntactic construct, type safety is quite easy to preserve. Still, its far from being a trivial thing to implement as it would require support of continuations on the compiler level. 
> 
> Cheers, 
> 
>  Taras
> 
> *Yes, current generators in Python are essentially coroutines but I think it important to keep the terminology clean. Generators are intended first and foremost as lazy sequence, well, generators. Coroutines are a much more versatile construct. 
> 
> 
> 
> On Fri, Dec 11, 2015 at 18:21 PM, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Looking for feedback on crafting a proposal adding generator functions to Swift. I understand this will likely be a very involved proposal at the language level, although I actually don’t know the complexity of the change within the Swift compiler itself.
> 
> 
> _______________________________________________
> 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/20151213/bc363eeb/attachment.html>