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

[Alex Gordon]

A coroutine library can be implemented in terms of the generators in Swift
2. Coroutines are different from generators in that they can send
information back to the subordinate function. This can be done using
additional ivars in the generator struct.

In a compiled language, Generator.yield() cannot be a library function, it
must be a statement or expression, as each yield is an exit point of the
function.

- Alex


On Sun, Dec 13, 2015 at 6:13 PM, David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> 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), 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> 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
>
>
>
> _______________________________________________
> 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/bc979b99/attachment.html>