[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#36407: closed (27.0.50; `plist-get', `equal' etc.

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#36407: closed (27.0.50; `plist-get', `equal' etc. and circular "lists")
Date: Fri, 28 Jun 2019 08:06:01 +0000

Your message dated Fri, 28 Jun 2019 08:05:10 +0000
with message-id <CAOqdjBd9GQH_UPV3BO2F14zLJ4tJYB_7Y=address@hidden>
and subject line Re: bug#36407: 27.0.50; `plist-get', `equal' etc. and circular 
has caused the debbugs.gnu.org bug report #36407,
regarding 27.0.50; `plist-get', `equal' etc. and circular "lists"
to be marked as done.

(If you believe you have received this mail in error, please contact

36407: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36407
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; `plist-get', `equal' etc. and circular "lists" Date: Thu, 27 Jun 2019 21:43:32 +0000
plist-get currently contains this code:

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

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.

Attachment: 0001-Remove-unnecessary-tortoise-checks.patch
Description: Text Data

Attachment: 0001-Make-equal-symmetric.patch
Description: Text Data

--- End Message ---
--- Begin Message --- 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 <address@hidden> wrote:
> 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.

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

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.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]