Ken Takata wrote:
> Hi Bram and mattn,
>
> 2016/7/3 Sun 6:27:36 UTC+9 Bram Moolenaar wrote:
> > 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.
>
> It seems that it's better to divide the lambda patch into several patches.
> E.g.:
>
> 1. lambda expression
> 2. closure
> 3. enable to pass a function to filter() and map()
>
> I wrote a patch for #3. I slightly changed the specification so that a
> function has both key and value as arguments. I also added some tests for
> filter() and map(). Please check.
Thanks, I like this splitup.
While writing an example I noticed that evaluation does not stop after
the function causes an error. This requires adding "abort" to the
function. I'll add a remark about that.
--
hundred-and-one symptoms of being an internet addict:
198. You read all the quotes at Netaholics Anonymous and keep thinking
"What's wrong with that?"
/// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
