GNU bug report logs - #36407
27.0.50; `plist-get', `equal' etc. and circular "lists"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36407 in the body.
You can then email your comments to 36407 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Thu, 27 Jun 2019 21:43:32 +0000

[Message part 1 (text/plain, inline)]

plist-get currently contains this code:

  FOR_EACH_TAIL_SAFE (tail)
    {
      <check for success>
      tail = XCDR (tail);
      if (EQ (tail, li.tortoise))
        break;
    }

I don't understand why the last two lines are there. They're
unnecessary for proper plists; for circular plists, they result in
unintuitive behavior; and they depend on details of the
FOR_EACH_TAIL_SAFE implementation.

Can someone enlighten me?

As a tangential issue, shouldn't `equal' be symmetric?

(let* ((l1 '#1=(0 1 2 . #1#))
       (l2 '(0 1 2 0 1 2 . #1#)))
  (equal l2 l1) => t
  (equal l1 l2) => "List contains a loop" error.
  (plist-get l2 1) => 2
  (plist-get l1 1) => nil

Patches attached.

[0001-Remove-unnecessary-tortoise-checks.patch (text/x-patch, attachment)]

[0001-Make-equal-symmetric.patch (text/x-patch, attachment)]

Message #8 received at 36407 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 36407 <at> debbugs.gnu.org
Subject: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Thu, 27 Jun 2019 15:51:37 -0700

[Message part 1 (text/plain, inline)]

> I don't understand why the last two lines are there.

I thought those lines were needed to avoid an infinite loop in 
pathological cyclic cases. But on further thought you're right, they 
aren't needed. I installed that patch; thanks.

> shouldn't `equal' be symmetric?

Yes, on its domain. But circular lists are outside its domain, and the 
documentation doesn't promise any particular behavior on them. It's OK 
if (equal a b) signals an error and (equal b a) does not. It's even OK 
if (equal a b) signals an error and a later call (equal a b) with 
exactly the same (unchanged) arguments does not (because the stack 
happens to have more room the second time). We still have symmetry in 
the sense that (eq (equal a b) (equal b a)) always either returns t or 
signals an error; it never returns nil.

I installed the attached doc patch to try to make this a bit clearer.

[0001-Improve-equal-and-array-doc.patch (text/x-patch, attachment)]

Message #13 received at 36407-done <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 36407-done <at> debbugs.gnu.org
Subject: Re: bug#36407: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Fri, 28 Jun 2019 08:05:10 +0000

On Thu, Jun 27, 2019 at 10:52 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> aren't needed. I installed that patch; thanks.

Thanks!

> > shouldn't `equal' be symmetric?
>
> Yes, on its domain. But circular lists are outside its domain, and the
> documentation doesn't promise any particular behavior on them. It's OK
> if (equal a b) signals an error and (equal b a) does not. It's even OK
> if (equal a b) signals an error and a later call (equal a b) with
> exactly the same (unchanged) arguments does not (because the stack
> happens to have more room the second time). We still have symmetry in
> the sense that (eq (equal a b) (equal b a)) always either returns t or
> signals an error; it never returns nil.

Thanks for your explanation, that makes perfect sense.

I was confused, in part, by the hash table code in internal_equal,
which appears to be designed to handle circular structures with some
generality.

On further thought, maybe that code is written for DAGs which contain
diamond-shaped subgraphs. However, those don't appear to be working
very well...

> I installed the attached doc patch to try to make this a bit clearer.

Thanks again! I'm closing this bug.

Message #16 received at 36407 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 36407 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#36407: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Fri, 28 Jun 2019 22:01:26 -0400

This causes the test json-serialize/object to fail. Ref eg

https://hydra.nixos.org/build/95582609

Message #19 received at 36407 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 36407 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#36407: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Sat, 29 Jun 2019 04:16:25 +0000

[Message part 1 (text/plain, inline)]

On Sat, Jun 29, 2019 at 2:01 AM Glenn Morris <rgm <at> gnu.org> wrote:
> This causes the test json-serialize/object to fail. Ref eg
>
> https://hydra.nixos.org/build/95582609

So it does. It actually tests an odd-length circular "plist", which
fails both before and after the change, but fails with a different
error code. Modification to the test attached.

[0001-Fix-json-serialize-object-test-failure.patch (text/x-patch, attachment)]

Message #22 received at 36407 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>, Glenn Morris <rgm <at> gnu.org>
Cc: 36407 <at> debbugs.gnu.org
Subject: Re: bug#36407: 27.0.50; `plist-get', `equal' etc. and circular "lists"
Date: Fri, 28 Jun 2019 22:02:43 -0700

Thanks, I installed that fix to the test case.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.