> Using strings here was just a quick way of making it work. What we > would really need is some kind of lambda function. So the argument > would be one of three types: > expression - mainly for backwards compatibility, but also allows > building the functionality from pieces. > function name or reference - for bigger functions > lamba function - for small functions > > That could be used in several places. > > Implementing a lambda function is not trivial though.
It is not very good idea: lambdas are better implemented as the same type as function references; basically the idea is the same as used in python: have structure with ob_type (at least with functions returning string used for string() and functions setting typval_T *tv given arguments and self (as tp_call in python)), ob_refcnt (for garbage collecting) and void*arg. Then you can have whatever you want, be it lambdas, proxies for python callable objects, anonymous or user-defined functions. We already want two different candidates for such change: I want python callables called without pyeval() proxy; you want lambdas. With such change these can live together and still count as one funcref type; without it would be 3 types. I can write a patch for this, but not until RFC for python interfaces is finished and implemented. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
