Michael Olson, 2007-08-28:
> Christian Ohler <[EMAIL PROTECTED]> writes:
>
>> Hmm, I haven't looked very closely at your recent changes, but if this
>> were so, shouldn't
>>
>> (defun make-counter ()
>> (let ((a 0))
>> (dvc-capturing-lambda ()
>> (incf (capture a)))))
>> => make-counter
>> (setq a (make-counter))
>> => (lambda ...)
>> (funcall a)
>> => 1
>> (funcall a)
>> => 1
>>
>> return 2 on the second call? Or how do you intend to implement state
>> variables?
>
> No. Only the value of the symbol is captured, not the symbol itself.
I guess the first sentence of my above message was too long. We seem to
agree now that state variables can't be implemented with
`dvc-capturing-lambda'.
> It kind of irritates me that a single flippant and completely
> unimportant remark that I made in the "Incremental parsing of log
> output" message about ways to retain state has led to a witch hunt about
> dvc-capturing-lambda.
It wasn't just your remark.
Your confusion about what `dvc-capturing-lambda' can be used for,
together with the fact that it broke in recent Emacsen,
together with the fact that you went through two iterations of fixing it,
together with Matthieu's remark that it was difficult to make it work in
the first place,
together with the fact that we don't even need it,
led to my criticism of the construct, its deceptive semantics, and what
a time sink it is.
Maybe I shouldn't have sent it as a reply to your message. I'm sorry if
that was irritating.
> For the record, I was incorrect in suggesting
> that dvc-capturing-lambda be used to track state; in retrospect, it was
> obviously wrong.
It was wrong, but this fact is obvious only in retrospect, and only to
you, after you've reworked all of `dvc-capturing-lambda's internals.
Your previous message still claimed the opposite. To a newcomer, it's
not obvious what works and what doesn't, here.
When I started working on DVC, I also wasted some time trying to figure
it out, and what its advantage over `lexical-let' was supposed to be,
but I fortunately gave up after a while. Still, I wish we could spare
others the time.
> dvc-capturing-lambda is not meant to be a full-fledged replacement for
> lexical-let, so it is meaningless to compare them.
I don't know what you mean here. The comparison is useful because their
use cases overlap. They don't have to be equivalent to permit a
meaningful comparison.
> It is not meant to be used in a nested fashion;
Odd. Doesn't every proper Lisp construct nest?
> it does not weave through its body argument
> in a complicated and time-consuming way,
The processing that `dvc-capturing-lambda' does isn't easy to
understand, either. My confusion about whether the non-compilable part
is really necessary and your commit message from about a week ago ("The
(funcall (lambda ...)) stuff looks superfluous, but I'll keep it in for
now") demonstrate this. The processing is a little bit simpler than
that of `lexical-let', and it doesn't "weave through its body argument",
but it certainly still qualifies as complicated.
I don't know about the "time-consuming" part. I don't think either of
them significantly affects compilation time.
The code is clearly in better shape after your improvements. But
readability is just a part of maintainability, and any purported
readability benefit of this macro is offset by the maintenance effort
caused by it in other ways.
Christian.
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
