Re: [Vala] Thoughts on asynchronous methods

[Jürg Billeter <j bitron ch>]

On Sun, 2009-09-13 at 16:16 +0200, Jan Hudec wrote:
> On Sat, Sep 12, 2009 at 13:34:27 +0200, Jürg Billeter wrote:
> > Hi Jiří,
> >
> > On Sat, 2009-09-12 at 00:27 +0200, Jiří Zárevúcky wrote:
> > > --------------------------------------------------------------
> > > 1. "yields" keyword is far from intuitive
> > > --------------------------------------------------------------
> > >
> > > [...]
> > >
> > > Personally, I would find following much more appropriate:
> > >
> > >      public virtual async void method (int arg) throws IOError;
> >
> > I agree with you here. The reason I've chosen `yields' is that I've
> > initially thought that the same syntax could be used for more generic
> > coroutine support. However, the focus was always on asynchronous methods
> > and there is no plan to integrate generic coroutine with the same syntax
> > anymore.
>
> Please, don't use 'yield' keyword in a way incompatible with C#, where (since
> version 2.0) it is used for generators just like in Python. E.g.
>
>     public IEnumerable<int> range(int start, int end) {
>         for(int i = start; i <= end; ++i)
>             yield i;
>     }

This should be `yield return i;'. We do not use/need `yield return' for
async methods, and I'm planning to add support for `yield return' for
generators in Vala the same way as it's used in C#. I don't see a
conflict here.

> This has nothing to do with asynchronous at all.
>
> I understand this is would be complicated to implement, but please at least
> don't use any of that syntax in an incompatible way.
>
> Virtual machines actually have it pretty easy to implement. They just stash
> away the running function state and than resume it. Vala can't easily do
> that, but I see two options for it:
>
>  - Generate the function in a special way so it is restartable. This would
>    mean to generate an anonymous class. All arguments and variables would be
>    converted to members of that class. Plus one extra member would remember
>    which point the function last returned at. Than if the function contained
>    no block-local variables, it should be possible to wrap it in a big case
>    (similar to what Duff's device uses) to jump to the correct point to
>    continue.

That's roughly what we already do for async methods, and the
implementation will be very similar for generators.

Jürg