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:
============================================================================================
lambda *expr-lambda*
------
\arg1, ...: expr1 lambda function
Lambda functions are the lightweight variant of |user-functions|. Differences
between them are:
1. Body of the lambda function is an |expr1| and not a sequence of |Ex|
commands.
2. Lambda function does not have its own scope dictionary. It does have scope
dictionary for |a:var| though. |l:| scope dictionary is inherited from the
place where lambda was defined (thus it is either |g:| scope dictionary or
|l:| dictionary of the function that defined the lambda).
You see, it is poor man closure.
3. If |a:var| is not found in lambda own scope dictionary it is searched in
|a:| scope dictionary of the function where lambda was defined (if any).
This does not apply to |a:000|, |a:0|, |a:1|, ... variables.
4. There are no dictionary lambdas.
5. Lambda is not globally recorded anywhere like |anonymous-function|.
NOTE: lambda function records the whole scope dictionary in its body and also
|a:| dictionary. That means that extensive generation of lambdas and
exporting them outside of generator function may lead to a huge memory
overhead.
============================================================================================
This is one of the easiest implementation. Commit with this implementation was
pushed to https://bitbucket.org/ZyX_I/vim, branch extended-funcref-lambdas, but
not to the mailing list (implementation is mostly untested and definitely
experimental). I have a few other suggestion for lambdas:
0. Current state.
Pros:
1. Simplicity of implementation.
2. No allocations for l: variables for lambdas.
3. Has access to a: of the caller.
Cons:
1. Lambda disallows freeing funccal structure until lambda is deleted.
2. No access to a:N variables. Requires modification of find_var_in_ht to
work. This likely may be worked around.
3. No local variables. Though if one is using expressions it is hard to
manipulate with them.
1. Make lambdas have exactly one local dictionary allocated once at creation.
Modify eval7 to copy all used variables to this dictionary on creation.
Arguments still go to a: dictionary allocated on each lambda call.
Pros:
1. Does not hold funccal structure.
2. Only those variables that are actually used will be recorded.
3. It is a python-like closure.
4. One less hash allocation compared to calling user function.
Cons:
1. Requires likely not so trivial modifications of eval7 and also
modification of other eval* to pass down the reference to l: dictionary.
2. One l: dictionary for all calls. Though if one is using … (see cons 3.
from p. 0.).
3. No access to a: of the caller (or we will get cons 1. from p. 0.).
2. Like above, but arguments go to local dictionary. Dictionary itself is
copied on lambda invocation.
Pros:
Same as above.
4. Copying dictionary should probably be faster then creating and populating
a new one. Needs some profiling.
Cons:
Same as above.
3. Like the current state (0.), but also has its own l: dictionary.
Pros:
Same as 0., except for 2.
4. Own scope where you can place something.
5. Adds a facility to create user functions that are real closures (likely,
but not necessary, limited to 2 nesting level; no limit on nesting is a bit
harder to implement, but it seems far from hard).
Cons:
Same as 0., except for 3.
// Note about the doc excerpt: anonymous functions are not recorded anywhere
*in extended-funcref branch*.
--
--
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.
