Re: [Vala] Thoughts on asynchronous methods

[Jan Hudec <bulb ucw cz>]

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:
> > I did some thinking on the subject of asynchronous (aka "yielding") 
> > methods. I'd like to share and discuss some of my ideas here.
> >
> > --------------------------------------------------------------
> > 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;
    }

    ...

    foreach(int i in range(10, 20)) ...

    (this is also allowed:)
    IEnumerable<int> r = range(10, 20);

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.

 - Implement a support library -- but it would require a bit of assembly --
   to allow executing a function in a separate stack. Than jongjumps would be
   used to switch between the stacks.

> As async support is still considered experimental, I think it makes
> sense to change the keyword now. I don't know whether we should use
> `async' or rather the unabbreviated `asynchronous' to be clear, although
> it's quite long. Any opinions?

To me, 'async' sounds obvious enough.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>