Christian Ohler <[EMAIL PROTECTED]> writes:
> `dvc-capturing-lambda' generates an expansion that can't be
> byte-compiled.
That's not true, and that's precisely what lead us to using
dvc-capturing-lambda.
> Its expansion conses a new `let' form every time it is run, which is
> then interpreted when called.
`lexical-let' also creates a let, and a lot of other ugly things when
expanded.
> Only the inner `lambda' form can be byte-compiled. This is
> unnecessarily inefficient.
I may have missed something, but looking at the expansion of
lexical-let, I see exacly the same kind of hacks : a byte-compilable
expression wrapped into a non-compilable lambda:
ELISP> (macroexpand '(lexical-let ((a 42))
(lambda () (setq a 5) a)))
(let
((--cl-a--
(make-symbol "--a--")))
(setf
(symbol-value --cl-a--)
42)
(list 'lambda ;; <- that's not byte-compilable
'(&rest --cl-rest--)
(list 'apply
#'(lambda ;; <- while this is.
(G5800)
(set G5800 5)
(symbol-value G5800))
(list 'quote --cl-a--)
'--cl-rest--)))
> `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.
`dvc-capturing-lambda' is really convenient to use, and makes the code
much more readable. You say which variable you want to take from the
definition context at the time you use the variable, not around the
function.
> We should aim to replace all uses of `dvc-capturing-lambda' by
> `lexical-let'.
As you have shown, `dvc-capturing-lambda' doesn't manage multiple
occurences of the same variable correctly, so lexical-let is obviously
better in this case, but I still don't see a reason to remove the
other occurences.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
