On Oct 25, 2013 1:31 PM, "Ingo Karkat" <[email protected]> wrote: > > On 15-Oct-2013 06:31 +0200, Nikolay Pavlov wrote: > > > On Oct 15, 2013 2:26 AM, "LCD 47" <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> On 14 October 2013, Bram Moolenaar <[email protected] > > <mailto:[email protected]>> wrote: > >> > > >> > ZyX wrote: > >> > > >> > > Since request for comments in thread with extended-funcref branch > >> > > patches has gone unnoticed I will repost it here. I currently have > >> > > somewhat working implementation of lambda functions in this branch > >> > > and want to discuss where to move on since any implementation I can > >> > > imagine has its downsides. ?Somewhat working? implementation I have > >> > > was done in one of the easiest ways possible. Here is the doc I have > >> > > written for new lambdas: > >> > > >> > How about a few examples that show how awesome this feature is? > >> > Especially before/after comparisons. > >> > >> Same here. What is the main purpose of all this? Syntactic sugar? > >> Reducing call overhead? Making complicated key maps less awkward? > >> Something else? I understand what Lambda functions are in Python (which > >> seems to be your inspiration for this design), but I can't really > >> translate the common use cases of Python lambda to Vim. So, what > >> problem does this solve? What would be the main use cases in Vim? > > > > 1. Partial function application. > > 2. Sorting with sort(). > > > > In frawor I constantly use generated functions that look like > > > > function d.F(...) > > return call(s:features['plugid'].name.func, > > [s:plugdicts['userplugid'], s:shadowdicts['userplugid']]+a:000, {}) > > endfunction > > > > 'plugid', .name, .func, 'userplugid' are all generated. This can be > > reduced to just "\...: call(feature[name].func, [plugdict, > > shadowdict]+a:000, {})". Still needs eval, unless p 1. is used, but > > already more lightweight. > > > > Third use is completely hiding the variables: shadowdict in the example > > can be generated in the function that exports features and not ever > > recorded in any global. > > > > Based on this uses I should stick with 1. If partial application is > > dropped or be considered to be allowed to be suboptimal sticking with 0. > > is an option. > > > > By the way, the first person I saw requesting lambdas is Bram in > > discussion to sort() proposed patch that will make sort() accept > > expressions. Thus the main reasoning was "sort() and partial application > > are good, but not enough. As it is relatively simple to add lambdas to > > my patch let us add them and see whether they will make Bram accept > > patch faster." Patch is incomplete without making map() and filter() > > accept funcrefs, but this is really trivial. RFC is here because maybe > > Bram sees more uses for lambdas then me. Quote: > > > >> 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. > > I've seen a few Vimscript frameworks (like your frawor) that look like > they're written from someone with a Python or Ruby background and make > intensive use of Dictionaries and anonymous functions. But this is > rather atypical. The usual plugin is structured like a shell script, > with a few (named) functions, nothing more. > > Even though I've written plenty of plugins, I only remember a few > occasions where a lambda would have been really handy, and the > workaround was an ugly script-scoped variable or explicit function. The > string evaluation in map() et al. certainly isn't beautiful, but it's > consistent with options like 'statusline'. > > Now, especially with your recent work on extending the Python interface > towards a fully-featured Vim integration, I wonder whether it isn't > sufficient for those people who want to do fancy object-oriented and > functional stuff to implement that Python altogether?! Adding stuff like > Lists and Dictionaries in Vim 7 was a right step; many people were > already crudely emulating them. With lambdas, I'm not so sure, > especially because there isn't an abundance of Vim developers, and many > patches and features are already waiting for Bram's review and approval.
As I said earlier I do not need lambdas much. They are good for frawor, but I sometimes think about writing python version of frawor rather then improving its VimL variant. I do find references to python callables handy though. Lambdas are an example of what one can relatively easy to do with a new branch which provides funcrefs to python functions. They also fulfill a request from Bram I quoted earlier. If I really was writing this for frawor then you would see some better designed code as a part of extended-funcref branch and no RFC. > -- regards, ingo > > -- > -- > 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. -- -- 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.
