I wonder if Rust could do something along the lines of F# computation
expressions <http://msdn.microsoft.com/en-us/library/dd233182.aspx> (or
Haskell's do-notation, if one is so inclined). This approach would put
more strain on the optimizer, which would have to deal with all those
lambda functions, but on the plus side, this is a more general approach,
and we could get both generators and asyncs out of it in one swoop.
Hmm, come to think about it, couldn't this be done with a syntax extension?
Vadim
On Sun, Aug 11, 2013 at 11:53 AM, Michael Woerister <
michaelwoeris...@gmail.com> wrote:
> Hi,
>
>> [...] The reason I'm bringing this up is because in case Rust ever wants
>> to gain support for bidirectional generators it should from the very start
>> have something like a "yield from" to not break the reverse forwarding.
>>
> Thanks for the extensive explanation. These iterators with bi-directional
> communication seem to be similar to what Ruby does (as described in the
> last section of my blog article).
> I'll have to think more about implications of and use cases for this kind
> of functionality. It would not be compatible with the current std::Iterator
> trait though. And it may encourage writing hard-to-read code/control flow.
> Though this is just a guess. Maybe its actually easier to read and follow
> than the struct-with-methods equivalent.
>
> I think Rust has an advantage over Python here, in that for every
>>> function the return type is explicitly declared. So, if a function
>>> returns an Iterator<T> (or better), one does not have to care about
>>> whether the function is implemented via 'yield' or if it returns a
>>> handwritten iterator.
>>>
>> You would think, neither do you in Python. The problem is actually not
>> so much the consuming of the function but the writing of it. In a regular
>> function you have execution as the function is called. In a generator
>> function the execution immediately suspends until you call next(). It's
>> very confusing for beginners and has caused in many, many broken WSGI
>> applications in Python (WSGI is the Python web abstraction protocol that
>> uses iterators).
>>
> Yes, it would certainly be more clear to not declare iterator fns as
> regular functions (because they aren't :)
> Though (IMO), it works rather well in C#. I don't have a strong opinion on
> the subject.
>
> Even more than that, how do you make an empty generator? [...]
>>
> I'd say, this should be a library function, something like
> `Iterator<T>::empty()`.
> With the `yield break` command from C# you could also have one canonical
> version:
>
> fn empty() -> Iterator<T> {
> yield break;
> }
>
> Lastly, in Python 3 we now are getting async IO support through
>> generators and the frameworks do weird things to make generator and regular
>> functions decorated with the same decorator, behave similarly in case
>> someone deletes the last 'yield' from the function. An explicit 'yield fn'
>> outside of the function solves this case, where a function degrades to not
>> having any yield expressions any more.
>>
>> Yes, in theory you could make a function that returns nil but is declared
>> as returning an iterator, just return the empty iterator for that type, but
>> that seems wrong.
>>
> I think I know too little about this topic say something useful here. But
> it seems like a specific library design issue.
>
> -Michael
> ______________________________**_________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
