Re: [Vala] Implicit lamdas/closures



Thanks for continuing this conversation, I know it is a distraction to your async work. I do appreciate it.

* Jürg Billeter wrote, On 04/11/08 12:14:
On Mon, 2008-11-03 at 20:15 +0000, Sam Liddicott wrote:
  
(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)
    

The code is all in a single function and a switch statement jumps to the
right statement.
  

This seems to mean that "yields" functions will be seen to have extra parameters when invoked from C, e.g. C users of a vala library; I suppose this will tie C uses into the particular async model.

Have you considered having entry-point wrapper-functions that merely call the main body with the correct switch value? (- Although I digress somewhat, and it no longer affects me, as callbacks probably won't need the "yields" modifier and their wrapper function will be the lambda anyway...)

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...
    

One major concern I have is how do you intend to pass values returned
from the callback back to the main method? The parametrized continue you
proposed seems to be too cryptic, do you have an alternative idea?
  
Do you mean the pastebin example:
(thing, secret) => { continue(thing, secret); return true; }

or the example in my recent message of:
(thing, secret) => { continue inline; return true; }

in which lambda arguments that are also defined in the main body are used to receive the callback data, otherwise they become local (and temporary) to the scope of the lambda itself?
Of course the lambda callback could do:
(thing, secret) => { main_thing = thing; main_secret=secret + "hee hee"; continue inline; return true; }

I don't think either is particularly cryptic if one knows that the feature exists, and for someone who doesn't - when they see it - it will certainly get their attention, so they won't miss it. If they don't know what it is they will know that it's something new/puzzling rather than come to the wrong conclusion - (and I think many would guess right).

Sam


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]