> > > I don't understand the fundamental difference with setting a variable
> > to an expression in string form, so that it can later be :execute'd, as
> > is already done for several options: ":help expr'<Ctrl-D>" shows me ten
> > of those (not necessarily all different).
> >
> > Expressions are invalid for :execute. I do not understand how &*expr
> > options are related.
>
> :execute "let x =" lambda
You said “so that it [expression in a string form] later be :execute'd”.
:execute expr
for an expression like `tr(s, "abc", "def")` is not valid. You execute here not
an expression, but an `:let` assignment containing an expression. Options do
not use `:execute` or anything `:execute` uses directly, they use the same
function `eval()` uses.
> Why not? I don't see this as a workaround: Write your expression as
> using an argument with a predetermined name; then
>
> :let lambda_arg = 123 * 456
> :exe "let result =" lambda
> :unlet lambda_arg " unless it has a persistent meaning
> " one reason to omit the :unlet would be if you want to use
> " the expression several times (possibly from different places)
> " with the same argument (or one that changes less often than
> " the expression is used); or else if the expression
> " modifies its own argument (but the latter would be
> " more appropriate for a full-fledged user function).
>
> or for a number of arguments, the "argument" variable could be a List or
> a Dictionary instead.
I need the exact list or dictionary, not their copy. string()ing it is not an
option. Hence I have this workaround with values recorded in globals. Hence
problems with GC.
Also do not use `execute 'let a='.lambda`. There is `eval()` which has far less
overhead and is more convenient to use in many cases.
> > It is bad for GC: generally you cannot know when
> > expression and attached variables are no longer needed. Globals are
> > always bad for threading, if this will ever go into vim. It adds a bunch
> > of unneeded code: generate global name, record value there, put name
> > into the expression.
>
> What is currently done for 'indentexpr' et al.? Even 'statusline' could
> be regarded as a kind of "expression" with a peculiar syntax; but of
> course it needs neither unletting nor garbage collection.
Again, how '*expr' options are related to lambdas? I never said a word about
lambdas being useful for them.
--
--
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.