bug#47992: [External] : bug#47992: 27; 28; Phase out use of `equal` in `add-hook`, `remove-hook`

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

>>> Perhaps `equal' can be fixed to do something better with closures?
>> There's no magic: `equal` has to check the structural equality, so it
>> has to recurse through the whole structure, including all the
>> closed-over variables to which it refers.
> Well, structural equality on closures is an arbitrary choice. One could
> simply refuse to compare closures structurally and treat them as opaque
> objects.

Currently we could do that for byte-compiled closures but not for
interpreted ones.

> The structural equality does not even perform alpha conversion.

It partly does actually, by accident, when the code is byte-compiled,
but only for the variables internal to the function and not for the
formal arguments (because they "escape" into the docstring).

Hopefully this will be "broken" at some point, when we add enough debug
info to bytecode to be able to find the value of (and set) local
variables by name.

> This is probably due to how binding works in Elisp?
>
> (equal (lambda (x) x) (lambda (y) y))

Equality on functions is fundamentally undecidable and it's nigh-on
impossible to provide a sane and well-defined "approximation" of it
either (at least not without significantly restricting the set of
optimizations that the compiler can be allowed to perform).

The upside is that this fundamental problem was the motivation for the
development of type classes in Haskell which are a great feature
(nowadays used in most proof assistants and in several other programming
languages such as Scala and Rust).


        Stefan