Re: [PATCH] (Updated) Run hook when variable is set

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Surely you can't say with a straight face that binding to unboundedness is
> not an absurd concept.

Where does the manual say such a thing?  AFAICT this absurd concept
comes from your interpretation of what's going on, and just shows that
your interpretation is not a good model.

> Either way, the behavior of makunbound is wrong.

You've said so enough times, but I haven't heard any concrete
alternative proposal so far.  Not that I'd advise you to spend time on
it, since this is a complete non-problem as far as I'm concerned.

>>>> - OLDVAL is either a list of one element containing the old value, or
>>>> nil (when that old value is Qunbound).
>>> Then run_varhook must cons. That'll generate a lot of garbage if you use it
>>> for profiling, or for debugging in a way where you don't just pause to
>>> inspect every hooked variable. Is that ok?
>> I think it's OK, yes.
> This seems to be the least-bad option, so I did it this way, even though it
> makes the API a bit gross. Unfortunately, when you do:
> (require 'cl)
> (setq x 0)
> (symbol-hook 'x)
> (benchmark-run-compiled 100000 (incf x))
> it now spends half the time doing garbage collection. That's a high price to
> pay to cater to the brain-dead misbehavior of makunbound.

Agreed.  Another option is to pass 2 more arguments, i.e. pass "OLDVAL
OLDBOUND NEWVAL NEWBOUND".  You still have the problem of returning
whether the actual new value should be bound or not.

I see you decided to use a special (uninterned symbol) value instead.
That's OK with me.

> so to account for the inversion, it would have to change to:
> if (!writeable) a...;
> else b...;
> which introduces an extra «not» operator.

This operator has 0 cost since any decent compiler will just swap the
two branches of the `if' instead of performing an actual `not' computation.


        Stefan