Re: Lisp watchpoints

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Actually, I think it's not that complicated:
>> - Look at the definition of SYMBOL_CONSTANT_P.
> There is a comment on Lisp_Symbol's `constant' field saying "If the
> value is 3, then the var can be changed, but only by `defconst'".
> However, I can't find any code that uses this value.

It's a mistake (I had such a thing working locally at some point but
I dropped it before I installed the code in the repository): I just
forgot to update the comment.

> Is it safe to ignore?

Yes.

>> - Change its name to SYMBOL_SLOWWRITE_P.
>> - Change the field it tests from being a boolean to being a 3-valued
>> thingy, with values "fullspeed", "hooked", and "readonly".
> Would it be sensible to implement "readonly" as "hooked" + some hook
> that signals error on write?

Could be, but I think I'd rather not take the risk that some advice
could turn nil's value to something else than nil.
IOW those vars currently marked as "read-only" should *really*
be kept read-only.

OTOH if we make sure that the "read-only" hook can't be
overridden/changed/skipped by Elisp code, it might be fine.

>> Maybe it'd be nice to make sure that "defvaralias" could be
>> re-implemented on top of those hooks, even though I don't think such
>> a reimplementation is desirable at this point.
> To do that we'd have to trap reads as well as writes, right?

I don't think so.  We just need to keep the two vars "synchronized" so
any assignment to one also changes the other.

> Which could be useful for debugging too.

I think a hook on variable reads is not a good idea.  Fundamentally the
issue is similar to the one for assignments, but the trade-offs work
differently:
- we currently don't have a CONSTANT_P check for reads, so adding
  a HOOKED_P check would incur an additional cost.
- When debugging it's much less frequent to need to catch reads than writes.
- The risk involved in running arbitrary Lisp code for a variable-read
  seems higher.

So the cost and risks are higher whereas the expected benefits are lower.
If/when dynamic-binding is the exception, maybe this could be
reconsidered but there'd also need to be a compelling argument in favor.


        Stefan