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