On Oct 15, 2013 2:26 AM, "LCD 47" <[email protected]> wrote:
>
> On 14 October 2013, Bram Moolenaar <[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.
> /lcd
--
--
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.
