From: Philip Kaludercic <philipk@posteo.net>
To: Ruijie Yu <ruijie@netyu.xyz>
Cc: Alan Mackenzie <acm@muc.de>, 62037@debbugs.gnu.org
Subject: bug#62037: (proper-list-p '#1=(a #1#)) => 2. It should return nil.
Date: Fri, 31 Mar 2023 07:25:12 +0000 [thread overview]
Message-ID: <87ilehpelj.fsf@posteo.net> (raw)
In-Reply-To: <sdvwn2x34up.fsf@fw.net.yu> (Ruijie Yu's message of "Fri, 31 Mar 2023 12:35:49 +0800")
Ruijie Yu <ruijie@netyu.xyz> writes:
>>> [...]
>>>> Doesn't this point resolve the issue?
>>>
>>> No, it doesn't. A circular list is defined (Elisp manual page "Lists
>>> and Cons Cells") as one where "some cons cell’s CDR could point to one
>>> of the previous cons cells in the list". A proper list (page
>>> "List-related Predicates") is one which is neither dotted nor circular.
>>>
>>> The list #1=(a . #1#) is clearly circular. proper-list-p should return
>>> nil for it.
>>
>> But (proper-list-p '#1=(a . #1#)) does return nil? [...]
>>
>> because #1=(a #1#)) is not a circular list, the cadr only has a
>> reference back to a the beginning of the list, but #1=(a . #1#)) is
>> cyclical because as you say a cdr points back to a previous cons cell:
>> [...]
>>
>>> The purpose of proper-list-p is surely to find out in advance whether an
>>> algorithm one wishes to run on a list can proceed without taking special
>>> precautions for dottedness or circularity. proper-list-p fails here.
>> [...]
>
> So, it all boils down to the fact that the current documentation is
> lacking and/or ambiguous, in terms of "the purpose of `proper-list-p'",
> as well as the two definitions of the adjective "circular", which are
> not interchangeable in different contexts.
It might be lacking, but I don't think the explanation is ambiguous.
"its last cdr is nil" might not be awfully formal, but it does describe
the problem.
> If we all agree that only some pieces of documentation need updating,
> then I will try to come up with a patch(set) in the upcoming few days --
> or someone else can, should one volunteers to do so. FTR, I am still
> waiting for a counter signature from FSF.
--
Philip Kaludercic
next prev parent reply other threads:[~2023-03-31 7:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 17:29 bug#62037: (proper-list-p '#1=(a #1#)) => 2. It should return nil Alan Mackenzie
2023-03-08 4:13 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-18 7:41 ` Philip Kaludercic
2023-03-18 8:29 ` Alan Mackenzie
2023-03-18 13:48 ` Philip Kaludercic
2023-03-31 4:35 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-31 7:25 ` Philip Kaludercic [this message]
2023-03-31 7:29 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-31 7:50 ` Eli Zaretskii
2023-04-01 14:16 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilehpelj.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=62037@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=ruijie@netyu.xyz \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.