bug#39529: 28.0.50; Metahelp does not contain help text

[Pip Cet]

On Wed, Feb 19, 2020 at 1:22 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2/18/20 11:56 AM, Pip Cet wrote:
>
> > if we rely on the precise
> > definitions of XHASH etc. that were in place prior to the January
> > changes, no "quick fix" was needed; it was simply the case that the
> > predicate used by hash tables created with :test equal diverged from
> > the built-in `equal' predicate in one more way than was already
> > documented. (Those documented deviations are that mutations of hash
> > keys won't cause rehashing, and that equal will sometimes signal for
> > (equal a b) but not for (equal b a)).
>
> I'm not aware of these deviations - where are they documented?
>
> What I see in the Emacs 27 documentation, under "Defining Hash
> Comparisons", is the statement that the hash and equality functions'
> "behavior should depend on only on properties of the keys that do not
> change".

That sentence is what I was referring to by "mutations of hash keys
won't cause rehashing", which is one of the deviations. The other one
is documented in objects.texi:

Comparing circular lists may therefore cause deep recursion that leads
to an error, and this may result in counterintuitive behavior such as
@code{(equal a b)} returning @code{t} whereas @code{(equal b a)}
signals an error.

> This is true of 'equal' and 'sxhash-equal' if one does not
> mutate any key that's in the hash table. So from what I can see, the
> predicates are supposed to be the same, it's just that one can't mutate
> keys.
>
> Also, I don't understand what is meant by "the predicate used by hash
> tables created with :test equal diverged from the built-in `equal'
> predicate". cmpfn_equal simply calls Fequal, so how can their behaviors
> diverge?

cmpfn_equal is only called when the numeric hashes are equal, so the
actual predicate used is sxhash_equal (a) == sxhash_equal (b) &&
Fequal (a, b). That diverged from Fequal (a, b) in the case where a
and b are markers, for example.

>
> >>> The pure-cons hash, and many other places, assume "equal" means
> >>> "equivalent" in some way. That's not true for bytecode objects, where
> >>> a function always returning `nil' can be equal to one always returning
> >>> `t'.
> >>
> >> Could you give an example of this? When I byte-compiled this:
> >
> > (defun f () (let ((x '(#1=(nil) . #1#)))
> >            (eq (car x) (cdr x))))
> > (defun g () (let ((x '((nil) . (nil)))
> >            (eq (car x) (cdr x))))
> >
> > That's somewhat contrived; more realistic examples where this might
> > actually be a problem would use string properties.
>
> Although this example is a good one that illustrates a bug (or at least
> a poorly-documented feature) in dumping, it hasn't changed because of
> the January 7 changes to sxhash.

True. My point was that "equal" is a problematic hash predicate, at
least currently.

> The same issue exists in Emacs 27 (and
> in Emacs 26 for that matter). So I'd rather address this issue
> separately, perhaps simply by documenting it for now.

Agreed.

> > I'll propose one more thing, which sounds horrible at first but might
> > be the least horrible option: accept that `equal', the function, and
> > `:test equal', the hash table predicate, have diverged significantly
> > already.
> Again I'm not following, because the two functions haven't diverged as
> far as I can see.

(defun hash-equal (a b)
  (let ((ht (make-hash-table :test 'equal)))
    (puthash a t ht)
    (gethash b ht)))

(hash-equal (point-marker) (point-marker))
(equal (point-marker) (point-marker))