From: Pip Cet <pipcet@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com
Subject: bug#39529: 28.0.50; Metahelp does not contain help text
Date: Wed, 19 Feb 2020 02:34:39 +0000 [thread overview]
Message-ID: <CAOqdjBdrB=4ypKiiwxgY7=CXVhicmKxe6Gbx0kofB=e-axWjfA@mail.gmail.com> (raw)
In-Reply-To: <aa08fc22-75b0-7fcd-0710-c8d009469d50@cs.ucla.edu>
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))
next prev parent reply other threads:[~2020-02-19 2:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 19:06 bug#39529: 28.0.50; Metahelp does not contain help text Federico Tedin
2020-02-09 19:22 ` Eli Zaretskii
2020-02-09 19:34 ` Eli Zaretskii
2020-02-15 23:25 ` Paul Eggert
2020-02-16 15:35 ` Eli Zaretskii
2020-02-16 16:51 ` Pip Cet
2020-02-16 19:43 ` Paul Eggert
2020-02-18 19:56 ` Pip Cet
2020-02-19 1:21 ` Paul Eggert
2020-02-19 2:34 ` Pip Cet [this message]
2020-02-19 9:00 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOqdjBdrB=4ypKiiwxgY7=CXVhicmKxe6Gbx0kofB=e-axWjfA@mail.gmail.com' \
--to=pipcet@gmail.com \
--cc=39529@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=federicotedin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).