Re: [Vala] Proposal for an improved delegate/lambda handling

["Sam Liddicott" <sam liddicott com>]

[My email server ate half my reply! Here's all of it]

That's pretty much where I'd got up to.

I was also trying to use libffi for it's trampoline for data-less callbacks.

For glib callbacks if the data pointer is not weak (I guess it always is 
weak) then the lamba vars can ref counted, otherwise then the lamda 
struct could maybe be free'd when "this" is freed at least, meaning the 
object will track it's lamba var instances.

Maybe the lambda vars should be fields of an implicit subclass of a 
lambda object to help manage this. Maybe different lambda base classes 
could be specified depending on the situation.

Currently in the samba C code the caller explicitly frees the lambda 
struct (of course) at the end of the callback.

Maybe in the vala code we can avoid using the word "return" except for 
the final return. This would cover continuation style code, but might 
not favour signal handler style events, but perhaps they are actually a 
different case anyway...

Sam


-----Original Message-----
From: Yu Feng <rainwoodman gmail com>
Sent: 19 October 2008 15:40
To: Sam Liddicott <sam liddicott com>
Cc: Ali Sabil <ali sabil gmail com>; Christian Hergert 
<christian hergert gmail com>; Vala Mailing list <vala-list gnome org>
Subject: Re: [Vala] Proposal for an improved delegate/lambda handling


On Sun, 2008-10-19 at 14:19 +0100, Sam Liddicott wrote:
> I like any method that allows the callback block to acess all
> variables from the original scope and also allows execution of the
> callback to fall-through into the original scope at the end of the
> callback block; implying that the whole function must be generated
> with labda-style local vars.

It is not easy to do in a (GLib and VALA)-consistent way. There is only
one user_data field in GLib callbacks and it is already used for 'this'.

Although it is possible to reuse this parameter for a 'local' variable,
in which we store every local variable, problems exist.

The lambda-style local vars has to be on the heap rather than the stack
so that it doesn't get immediately destroyed when the parent code block
is no long in execution. But putting local variables in the heap
contradicts with the way C works; therefore the resulted c code has to
be really messy. It is not a big deal anyways since VALA already
generates messy C code in many situations.

More importantly, there seems to be little possibility to free these
lambdas because we don't know when they are no longer in use. Neither
can we disconnect signals because we lost the track of the 'user_data'
parameter if we are out of the function that connects the signal.

The following code shows a possible implementation.

struct has_lambdas_local_type{
int ref_count;
GObject * this;
int local_1;
int local_2;
int par1;
};
void local_unref(gpointer local);
void local_ref(gpoitner local);

void lambda1 (...., struct has_lambdas_local_type * local) {

}
void has_lambdas (GObject * this, int par1) {
struct local_type * local = g_new0(struct local_type, 1); /*inevitably
leaked*/

local_ref(local);
local.this = this;
local.par1 = par1;

...
..
do stuff with local.local_1, local.local_2 and such.
...

local_ref(local);
g_signal_connect(..... , lambda1, local);
local_ref(local);
g_signal_connect(..... , lambda2, local);

....
playing with local.local_1, local.local_2, again.
....

local_unref(local);
return;
}



Yu
> Sam
>
>
>
> ______________________________________________________________________
> From: Ali Sabil <ali sabil gmail com>
> Sent: 19 October 2008 11:31
> To: Christian Hergert <christian hergert gmail com>
> Cc: Vala Mailing list <vala-list gnome org>
> Subject: Re: [Vala] Proposal for an improved delegate/lambda handling
>
> Here is another set of proposed syntaxes, so that the post_request()
> looks like this:
>
> client.post_request("GET ...") {
>     debug ("Got Response: %s", response);
> } {
>     debug ("Got error: %s", error);
> }
>
>
> Another possible syntax would be:
>
> client.post_request("GET ...") {
>     (response) => {
>         debug ("Got response %s", response);
>     }
> }
>
>
> which in the case of a callback+errback would look like:
>
> client.post_request("GET ...") {
>     (response) => {
>         debug ("Got Response %s", response)
>     }
>     (error) => {
>         debug ("Got error %s", error);
>     }
> }
>
>
> This 2nd syntax is actually inspired from Scala. Scala supports
> currying, as well as optional parentheses for parameter passing,and
> the ability to substitute parentheses for curly brackets in some
> place. This set of feature combined together allow building methods
> and functions that look and feel like control structure. (At least
> that's what I understood during a short trip to the Scala world).
>
> Thanks for all your feedback.
>
> --
> Ali
>
>
> On Sun, Oct 19, 2008 at 2:00 AM, Christian Hergert
> <christian hergert gmail com> wrote:
>         I like it. Might get confusing if someone wanted to mix direct
>         delegates and anonymous ones though.
>         
>         -- Christian
>         
>         
>         On Sat, Oct 18, 2008 at 4:14 PM, Yu Feng
>         <rainwoodman gmail com> wrote:
>         > On Sat, 2008-10-18 at 22:57 +0200, Ali Sabil wrote:
>         >> Hi all,
>         >>
>         >> I would like to start a discussion about a small syntactic
>         sugar
>         >> addition to Vala, that would in my opinion slightly improve
>         the
>         >> situation with asynchronous code. The following code sample
>         should be
>         >> self explanatory about my proposal:
>         >>
>         >> delegate bool HttpResponseCallback (string response);
>         >>
>         >> public class HttpClient : Object {
>         >>     public void post_request (string request,
>         HttpResponseCallback cb)
>         >> {
>         >>         cb ("Hello world");
>         >>     }
>         >> }
>         >>
>         >> // Current State
>         >> var client = new HttpClient ();
>         >> client.post_request("GET ....",  (response) => {
>         >>         debug ("got response %s", response);
>         >>         return true;
>         >>     }
>         >> );
>         >>
>         
>
>
> [The entire original message is not included]
> _

[The entire original message is not included]