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

[Stefan Monnier]

>> It shouldn't either.  This issue of which kind of advice to use is not
>> specific to this variable, so there's no need to put it there.
> It's an unusual function.

I don't see why it should be special: it take the symbol that's about to
be changed, its old/current value, and the candidate new value and returns
the actual new value that should be used.
Nothing special that I can see about that.

> interaction with «let», and how to deal with the case of makunbound, all
> need to be documented somewhere,

Yes, handling unbound does require special care and needs to be
documented, but it doesn't affect the way add-function is to be used.

> and for completeness, it makes sense for the documentation to also
> cover the case of not overriding the return value.

How to override the value or block the assignment can be inferred from
the above description.

> If not in the docstring, then maybe in the manual?

If you want to give examples, then indeed the manual would be a good
place for it.

>> Actually I don't see these as two independent elements combined
>> into one.  I see it as a single value with 3 levels:
>> - any write you want
>> - write vetted by Elisp code
>> - no write at all
> If there's just :before advice (e.g. a profiler), then the write is
> not vetted.

It is vetted, it's just that the vetting function decides not to always
let things pass through.

>> So far we've been extra careful to try and make sure Qunbound doesn't
>> escape into Elisp world.  I don't think we want to reconsider this
>> design choice, since adding this Qunbound as a "normal" value in Elisp
>> will just create the need for another special "really unbound" value.
> Qunbound already escapes: you just have to use makunbound instead of «set»
> to set it, and boundp instead of symbol-value to read it.

That doesn't let Qunbound escape.  It gives you access to the concept
and lets you control put (and check for) Qunbound in a symbol's
`value' slot.  But you don't actually get access to that value, so you
can't store it in other slots of a symbol, or in a vector, list, ...

> I've removed «void». I recommend making makunbound stop working on
> non-globals too.

`let' on dynamically-scoped variables doesn't make them non-local.

Or rather, whether it does or not is a philosophical question (does
`let' create a new variable which shadows the outer one, or does it just
temporarily change the value of the variable?).

Once you introduce multiple threads with shared memory, those threads
get to test their theory, and usually it's considered that let-binding
in that case should have only a thread-local effect, whereas the current
implementation technique used in Emacs would naturally lead to the
let-bindings having a global effect.

>> - 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.

>> - Use a special value to represent "unbound", e.g. a special keyword like
>> `::value--unbound::'.
> (because it's impossible to set a hooked variable to that keyword),

Yes, that's a disadvantage.

> Or to avoid needing to cons in run_varhook, it could specbind something like
> Qsymbol_newval_void (to t if the new value is Qunbound), so the hook

Yuck.  That's even worse than using a value that is hopefully never
used elsewhere, like `::value--unbound::'.

> Would ⌜const_hooked⌝ be ok?

How 'bout `writable' with values yes/no/thrufunction?


        Stefan