A `yield` construct in the vein of C#

[rust-highfive]

Issue by bstrie
Friday Jul 12, 2013 at 13:46 GMT

For earlier discussion, see rust-lang/rust#7746

This issue was labelled with: A-an-interesting-project, E-hard, I-wishlist in the Rust repository

---

@thestinger has mentioned this several times as a wishlist item. This is a feature that greatly simplifies the implementation of external iterators by allowing them to be compiled to state machines at compile time (did I get that right?). See http://msdn.microsoft.com/en-us/library/vstudio/9k7k7cf0.aspx for reference.

While we shouldn't expect this for 1.0, it might be prescient to reserve the keyword right now.

Nominating for far-future milestone.

[errordeveloper]

I believe yield conveys pretty much the same meaning in other languages, including Python, Ruby and Lua. I think it's very appropriate to remove "C#" from the title.

[thestinger]

@errordeveloper: It's not implemented with a compile-time state machine in Python and Ruby. C# in the title is definitely appropriate, because (AFAIK) there isn't another language with a comparable feature. The proposal is not about generators / coroutines built on context switches.

[errordeveloper]

@thestinger sure, I didn't fully realise that.

[sfackler]

A decently in depth discussion of yield support in C++: http://isocpp.org/files/papers/N4134.pdf

[errordeveloper]

@sfackler great find!

[errordeveloper]

If Am I understanding correct that someone needs to make a pull-request with an actual RFC write-up, and if so, has anyone here already started on that or at least intending to do so?

[sinistersnare]

@errordeveloper #53

[zwarich]

@errordeveloper I have started thinking about the implications of a 'yield' construct for borrow checking, which is something that past proposals have sort of glossed over. I haven't been too anxious to write up an RFC, because there is no chance that it will be considered before 1.0.

[Lucretiel]

Is the fact that it's implemented as a compile-time state machine significant? The usage pattern to the developer is the same as in any other language, albeit with explicit typing.

[errordeveloper]

It is, as it makes this feature most useful. State machines generated at
build time can be validated/safety-checked as well as optimised by the
compiler plugin that implements it.

On Wed, 19 Nov 2014 20:46 Lucretiel notifications@github.com wrote:

Is the fact that it's implemented as a compile-time state machine
significant? The usage pattern to the developer is the same as in any other
language, albeit with explicit typing.

—
Reply to this email directly or view it on GitHub
#388 (comment).

[Ericson2314]

That is an interesting bunch of libraries there! It looks like your monad macro has bind as a primitive like Haskell's. I wonder if performance could be improved by using map and join alone as primitives to remove some "administrative lambdas".

Either way (as pipes will contain FnOnces even if the core monad parts don't), it would be nice if there was some way to add an #[inline] to the function the once closure sugar desguars into. Maybe that might help with code locality.

[gnzlbg]

Here the latest Kohlhoff paper "Resumable Expressions", a new lower-level c++ alternative to await that allows implementing yield at the library level and combines stackless and stackfull coroutines:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4453.pdf

[Lucretiel]

I can't claim to be much of a fan of this proposal. He completely ignores what I think is the major advantage of the await/async (in python: yield from/coroutine) model: explicit control flow shifts. One of the major side benefits to single-threaded asynchronous design, as opposed to multithreaded synchronous, is that the control flow is only ever in one place at once. This means that a lot of the state-sync and atomicity issues in multithreaded design can be avoided. Compounding this advantage is the fact that, with await/yield from, all context shifts are explicit. In effect this means the developer can guarantee that between this await and that one, no other coroutine will touch any shared state. As an example, I used this to my advantage when writing an IRC-like chat room using python asyncio, where I had the list of logged in users as a dict mapping user ids to connection objects. Because I could guarantee exclusive access to this object in a given coroutine' between yield froms, I didn't have to worry about locking it, creating a local copy of it, or anything like that. Unfortunately, in the proposed resumable model, this advantage is lost. Any function could conceivably result in a context switch. The situation is slightly improved by the fact that such functions are explicitly tagged "resumable", but because merely calling the function can cause it to begin running or suspending, there's no way to separate the act of instantiating the function with that of stepping through it.