Ken Takata wrote:

> 2016/7/14 Thu 15:43:11 UTC+9 mattn wrote:
> > On Thursday, July 14, 2016 at 12:49:58 PM UTC+9, ZyX wrote:
> > > 2016-07-13 19:17 GMT+03:00 mattn <[email protected]>:
> > > > On Wednesday, July 13, 2016 at 4:11:59 AM UTC+9, Bram Moolenaar wrote:
> > > >
> > > > Well, I wonder this lambda will be useful. At the first, we hoped to 
> > > > call statements in lambda. But the implementation you will include into 
> > > > vim can't do because it only allow expressions. It's similar to 
> > > > python's lambda. python's one doesn't allow statements. So usecase are 
> > > > limited to use. I don't have strong opinion but I'm thinking that this 
> > > > is an new expresssion or language for the lambda. It will demand to 
> > > > learn the new expression for the users.
> > > 
> > > Vim has `execute()`. Python-3 has `exec()` function (Python-2 has it
> > > as a statement). Lambdas do not usually allow statements because they
> > > are to be used in contexts which requires return value (e.g. in Python
> > > this is sorted()/list.sort(), defaultdict(), re.sub[n] (BTW, it is
> > > good idea to have `substitute(s, pattern, funcref, flags)` to work
> > > like `substitute(s, pattern, '\=funcref(submatch(0), submatch(1), …)',
> > > flags)`)). Lambdas are also used as a replacement for
> > > `functools.partial` (python)/`function(fref, args, self)` (VimL) in
> > > cases when they do not apply (e.g. when one needs to fix not the
> > > first, but second or other arguments), but this requires closures.
> > 
> > execute() doesn't have scope. So:
> > 
> > call execute("let a = 1")
> > echo 1
> > 
> > This define new variable in global scope. I want anonymous function. If 
> > execute() works with the scope, for example "let a = 1" mean "let l:a = 1", 
> > It's so great.
> 
> Currently "{args -> expr}" has its own scope.
> 
>   :echo {-> execute("let a = 1")}()
>   :echo a
>   E121: Undefined variable: a
>   E15: Invalid expression: a
> 
> 
> BTW, because of its own scope, the following code doesn't work:
> 
>   let list = [ /* some data */ ]
>   let l:threshold = 10
>   filter(list, {idx, val -> val > l:threshold})
> 
> As ZyX pointed out, function() can be used (but redundant):
> 
>   filter(list, function({th, idx, val -> val > th}, [l:threshold]))
> 
> Closure might be useful for this, but it would be the next step.

The question is, once we do implement closures, are all lambda's a
closure or does it need to be defined?  In the last case we may wanto to
explore now how that's done.

If a closure is really cheap we may just make all lambda's a closure.
But when it's not cheap, and they are used in something long-living like
a callback, we should make it optional.

I suspect it's not cheap, especially when lambda's live longer.  And
they are created in a bigger function (e.g. to start a job).

Instead of keeping the whole context, another way is to explicitly
specify what to take from the context:
   {arg, USE var -> expr}
But that will look ugly to anyone using closures elsewhere.

So long as we only use variables from the context, we could use a
prefix, like in your example:
   let l:threshold = 5
   filter(list, {idx, val -> val > @l:threshold})

But this requires parsing the expression to find out what is used from
the context, which is tricky.

So it might be best to have some way to specify a function or labmda is
a closure.  For a function we can just add an argument, like we alrady
have "dict" and "abort".

Some alternatives:
        { arg => expr }    (probably too subtle)
        {@ arg -> expr }
        { arg CTX => expr }
        {{ arg -> expr }}

Can't say any of these is nice.  At least none of them mean we have to
change the syntax of lambda.


-- 
   GALAHAD hurries to the door and pushes through it.  As he leaves the room
   we CUT TO the reverse to show that he is now in a room full of bathing
   and romping GIRLIES, all innocent, wide-eyed and beautiful.  They smile
   enchantingly at him as he tries to keep walking without being diverted by
   the lovely sights assaulting his eyeballs.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

Raspunde prin e-mail lui