Re: [Vala] Implicit lamdas/closures

["Sam Liddicott" <sam liddicott com>]

Jürg, I'll call your stuff "async" and mine "callbacks".

You're right that I can do most of what I need with continuation lamdas.

Perhaps I could abuse the keyword pair "continue inline" to cause the lambda to invoke the main body at the 
correct point.

(I'm not sure how you are generating the continue entry points, but if you are using wrapper functions, then 
the continuation lambda would just be a way of specifying the body, type signature and name of that wrapper, 
instead of whatever the async model would do)

I would also need to use something like the keyword yield to specify a continuation point and that the return 
should not free the closure.

I could probably do without the yield blocks I suggested and have "continue inline" refer to the next yield 
statement, thus avoiding polluting the language too much; 

despite this though I think the yield bocks are safer as they ensure that the  "continue inline" lambda is 
specified in the yield block and prevents the callback occuring in a diffent block by careless placing of the 
next yield statement 

So it seems that "continue inline" and yield blocks are the only outward language polutions I'm proposing, 
and maybe not yield blocks...

Continue inline is important to unroll what would otherwise be nested lamda soup - in contrast to which 
nested methods would be better, but continue inline is better still. If it helps I'll post the samba 
composite-connect which is a multi-stage (with branching) async authentication protocol negotiator. (i.e. It 
has to find out what authentication is supported and make one of them work).

Unrolling this into one function is my holy grail for callbacks.

Thanks for your input.

Sam
-----Original Message-----
From: JürgBilleter <j bitron ch>
Sent: 03 November 2008 07:34
To: Sam Liddicott <sam liddicott com>
Cc: Michael 'Mickey' Lauer <mickey vanille-media de>; vala-list gnome org
Subject: RE: [Vala] Implicit lamdas/closures


On Mon, 2008-11-03 at 07:25 +0000, Sam Liddicott wrote:
> -----Original Message-----
> From: JürgBilleter <j bitron ch>
> Subject: RE: [Vala] Implicit lamdas/closures
>
> > The generated C code uses GAsyncReadyCallback 
> > and GAsyncResult from GLib/GIO.
>
> Are you inclined to support use by plain boring delegate style
> callbacks where libraries have their own async framwork and just want
> a delegate to use as a callback?

The main issue I see is that the delegates probably all look a bit
different, which may make it hard to implement in a generic way. It
should be possible to write a backend plug-in to support a different
async framework in the future.

Do you have a code example, so that we can see whether that allows a
generic implementation or not?

Jürg