Matthieu Moy, 2007-08-26: > 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.
Well, the expansion can't be entirely byte-compiled, which is what I said in more detail later on, but you're right that `lexical-let' is no more byte-compilable than `dvc-capturing-lambda'. (And, thinking more about it, it seems to me now that this kind of macro necessarily has an interpreted part in Emacs Lisp.) So I was mistaken about the efficiency point in my previous message. (There's only one efficiency advantage that `lexical-let' might have, and that is that it is part of Emacs and will therefore benefit if any of the Emacs maintainers decides to improve it. For example, if the lexbind branch (which I'm not familiar with) ever gets merged, I'd expect `lexical-let' to become faster, but not `dvc-capturing-bind'.) >> `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. This is subjective. I think `lexical-let' is more readable since it simply implements the lexical variable binding semantics that practically all other languages with closures have, while `dvc-capturing-bind' is not a well-known construct. But the difference in readability is minor. >> 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. The fact that our implementation of `dvc-capturing-lambda' was brittle enough to break until Michael fixed it indicates that there's a nonzero maintenance cost to keeping it. Are you really convinced that it is bug-free now? (For example, I suspect that it doesn't nest correctly.) Also, its semantics are difficult to predict and/or under-documented, otherwise Michael wouldn't have suggested using it for state variables even though that won't work. There's nothing wrong with writing language extensions, but if there's a more general, much better-tested alternative maintained by others as a standard part of Emacs, we shouldn't waste any effort on maintaining our own variant. Christian. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
