Ken Takata wrote:
[...]
> > > > Yes, that is an option. It does restrict the situations when it can be
> > > > used, but since a multi-statement lambda quickly becomes unreadable,
> > > > there may not be much use for it anyway.
> > > >
> > > > It does require the possibility to create a closure with a nested
> > > > function, in case we do need multiple statements, but if we do support
> > > > closures it should be done for both lambda and normally defined
> > > > functions anyway.
> > > >
> > > > I do not like the cryptic syntax. I think the word "lambda" is good,
> > > > unless we can think of something that is easy to recognize.
> > > > One possible option is to focus on using the "gives" token:
> > > >
> > > > { a1, a2 -> a1 + a2 }
> > > >
> > > > Even without an argument it can still be recognized:
> > > >
> > > > { -> string(Today()) }
> > >
> > > This is way harder to implement, `{` already defines a dictionary and
> > > it may also be used for variable names, what already requires a “call
> > > eval1 twice” hack. `\` has no such problem, and I do not see this too
> > > cryptic. If you think that `->` is necessary, it is better to prefer
> > > `\args -> expr1` over `\args : expr1`, not `{ args -> expr1 }`.
> > >
> > > Prefixing lambda with `lambda` keyword makes this easy, but way too
> > > verbose.
> >
> > I do think that the backslash (or any other special character that might
> > be available) makes it ugly.
> >
> > Although we can find the end of the expression without the "}", mistakes
> > will be very hard to figure out. Also reading back a lambda that's
> > passed as an agument to a function with many arguments will make the {}
> > part easy to spot. I have done this in Zimbu and I'm happy with how it
> > looks.
> >
> > I don't think it's hard to implement: When finding a "{" look forward,
> > skipping over [a-zA-Z0-9 ], if "->" is found it's a lambda.
>
> Here is an experimental patch:
>
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/90ea467da862bc2eaf59454f75b8faea34604a1e/lambda2.patch?fileviewer=file-view-default
Well, that was fast.
> * Support only one expression.
> * The "a:" prefix cannot be omitted.
> * No closures.
> * Inefficient "{" parser.
>
> Both mattn's patch and ZyX's code are partly used.
> Nested lambdas are also supported like ZyX's example:
>
> :echo {a -> {tmp -> [a:tmp, a:tmp + 2, a:tmp + 5]}(a:a * 5)}(2)
> [10, 12, 15]
>
> Hmm, it's hard to read.
I understand that using the a: previx for arguments is consistent with
functions, but I think we better not do it that way. I keep forgetting
to add "a:" to arguments and inside a closure they are even less useful.
> BTW, I googled lambda expressions in some other languages.
>
> Python:
> lambda args: expr
>
> Ruby:
> lambda{ |args| ... }
>
> Java:
> (args) -> ...
>
> JavaScript
> (args) => { statements }
> (args) => expr
>
> C++:
> [](args){ ... }
>
> Haskell:
> \args -> expr
>
> Scala:
> (args) => expr
Using the "{ args -> expr }" syntax isn't so strange.
I also like that calling it immediately does not require extra (), as
the nested lambda example shows.
--
How do I set the laser printer to stun?
/// 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.
