--- 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:
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
Description: Text Data
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.
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.
--- End Message ---