Michael Olson, 2007-08-24:
> - Its state variables may be either generated symbols via (capture ...)
> statements in dvc-capturing-lambda, or permanent buffer-local
> variables which are defined outside of the function with a proper
> prefix, or can be &optional arguments that come after the required
> arguments (these arguments are passed to the next instance via
> run-at-time).
I don't think `dvc-capturing-lambda' can be used for state variables (at
least not directly), since it will use a different gensym for each
occurrence of a variable.
For example,
(let ((a 4))
(funcall (dvc-capturing-lambda ()
(setq (capture a) 5)
(capture a))))
-> expands to something like
(let ((a 4))
(funcall
`(lambda ()
(let ((dvc-gensym-uniq-12 ',a)
(dvc-gensym-uniq-11 ',a))
(funcall
(lambda ()
(setq dvc-gensym-uniq-11 5)
dvc-gensym-uniq-12)))))
=> 4
This also looks like, in addition to not handling multiple occurrences
of the same variable sensibly, `dvc-capturing-lambda' generates an
expansion that can't be byte-compiled. Its expansion conses a new `let'
form every time it is run, which is then interpreted when called. Only
the inner `lambda' form can be byte-compiled. This is unnecessarily
inefficient.
`lexical-let' doesn't have any of these problems. Also, it ships with
Emacs. I don't see why DVC needs its own idiosyncratic utility macro.
We should aim to replace all uses of `dvc-capturing-lambda' by
`lexical-let'.
Christian.
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
