Ken Takata wrote:
> 2016/5/27 Fri 22:38:34 UTC+9 Ken Takata wrote:
> > Hi mattn,
> >
> > 2016/4/18 Mon 0:30:19 UTC+9 mattn wrote:
> > > Hi, Bram and list.
> > >
> > > Updated lambda patch to be applied for latest code.
> > >
> > > https://gist.github.com/mattn/5bc8ded21e1033c9c0ea8cd5ecbbce11
> > >
> > > This include examples for timer on help file. I'm thinking lambda() have
> > > cooperative to work with job/timer/channel.
> > >
> > > So I hope to add this into vim8. How do you think?
> > >
> > > Thanks to k-takata, haya14busa, and all of members on vim-jp.
> >
> > I have tested the lambda patch with the latest Vim and I found two problems.
> >
> > 1. garbagecollect_for_testing() was renamed.
> > 2. Test_lambda_with_timer() fails on Cygwin. It seems that we need margins
> > as we do in test_timers.vim.
> >
> > Please check attached patch.
> >
> > I hope that the lambda patch will be merged in Vim 8.0.
> > This makes filter(), map() and sort() easy to use.
> > It also works nicely with job/channel/timer features.
>
> I have merged my patch into your patch, and also fixed that the function
> declaration was not sorted in alphabetical order.
> Please check the attached patch.
I have mixed feelings about this implementation. This needs more
thoughts and discussion.
One of the problems with the current use of a string for an expression,
as it's passed to map(), filter(), etc., is that this is a string, which
requires taking care of quotes.
Using lambda() for that doesn't have an advantage, it's only longer:
:call map(mylist, '"> " . v:val . " <"')
:call map(mylist, lambda('"> " . v:val . " <"'))
Perhaps we can define the lambda not as a function call, but as an
operator. Then it will be parsed differently and we don't need to put
the expression in quotes. We do want to be able to define it inline, as
a function argument. We do need something around it, so that it's clear
where the end is. Using {} would work, it's similar to a statement
block in most languages.
We would also like to specify arguments. We could separate the
arguments from the statements with a "gives" symbol. That could be ->.
This avoid the strange use of v:val and v:key to pass values to the
expression, like map() does.
call Func(arg, lambda{v -> return v * 3.12})
That way we can do this:
call map(mylist, lambda{v -> return "> " . v . " <"})
In most cases only one statement is needed, but having a few more should
be possible. Using | to separate statements hopefully works:
call Func(arg, lambda{ v -> if v < 0 | return v * 3.12 | else | return
v * -3.12 | endif})
Something like that. If it gets too long it's better to just define a
function.
The implementation also takes items from the context, thus creating a
closure. I don't think that should be specific to a lambda, defining a
function inside another function should be able to do the same thing.
After all, a lambda is just a short way of defining a nameless function.
In the implementation it seems the dictionary storing the function-local
variables is kept for a very long time. This relies on the garbage
collector. It's better to use reference counting to be able to free the
dictionary as soon as it's unused.
Also, the lambda always keeps the function-local variable dict, even
when it's not actually used. That makes lambdas a expensive.
It would be better to explicitly state the lambda is using its context.
Then we can also do that with ":function", so that we are not forced to
use a lambda if we want a closure.
However, I'm not sure we need this. It is possible to bind a function
to a dictionary, which can then contain anything that's to be kept
between calls.
Being able to pass a function to map(), sort(), etc. is good. However,
it looks like in the implementation only VAR_FUNC is supported, not
VAR_PARTIAL. It should be both.
--
What is the difference between a professional and an amateur?
The ark was built by an amateur; professionals gave us the Titanic.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/d/optout.
