From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Negative nth index Date: Wed, 25 Dec 2024 13:04:38 +0000 Message-ID: <87y1039aoa.fsf@protonmail.com> References: <865xnc6u9n.fsf@gnu.org> <87jzbs9jlk.fsf@gnu.org> <87r05wahsi.fsf@protonmail.com> <350E9109-04F6-4C20-B0F6-37C0A482DAD3@gmail.com> <87ed1w9glz.fsf@protonmail.com> <5D930F52-CD28-4E5E-89B2-1E9DC3945011@gmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Stefan Kangas , Tassilo Horn , Eli Zaretskii , Anand Tamariya , emacs-devel@gnu.org To: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 14:10:08 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tQR9L-00036n-Ry for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 14:10:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQR97-0005E3-8q; Wed, 25 Dec 2024 08:09:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQR4B-00038e-NE for emacs-devel@gnu.org; Wed, 25 Dec 2024 08:04:49 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQR4A-0008IZ-8Z; Wed, 25 Dec 2024 08:04:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735131883; x=1735391083; bh=iEOdaj0klUlzDtSSzubeqfGIsRKP74ZfNdLIYldjfkc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Oi/lGrd/nMDr0ipGTTzJW9Xmrworne+/yNZY3VfKfhpc0pXqHDCF1SjHpfOdIP2Rr xRw1KFNexAyxlbagzQJOyF+jR1J7rBXC1xZAjnSlL/rqJnLZxN5NmpHXqH7lPDhgMA Dnn32LEOILDiP4kjnyz3Km0AkmLCXdEhmVBmvo9x2Y6MXJNzkIIoDT332TtJ7eiaqL RimPgxBl2KLXzIDycYeLyGzdqpi2GjlVV6akWUVB5F4SuBXDE+sUjcIgIrcAw1OBgw C37jWbETtbYF64iQbfqZg3PXWTKqy/ZK4YWVi536MgeTCRQtarPj9Kp9JsW5TVth5/ ouFw+QFTMxC5Q== In-Reply-To: <5D930F52-CD28-4E5E-89B2-1E9DC3945011@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b23d460ef179deb3f0f98cb6bc98c41cd7d4d464 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 25 Dec 2024 08:09:51 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327089 Archived-At: Mattias Engdeg=C3=A5rd writes: > 25 dec. 2024 kl. 11.56 skrev Pip Cet : > >> s/nth/nthcdr/g in my email, then. Of course the two should behave >> analogously, the question is whether they should both throw an error (my >> opinion) or shouldn't. > > The behaviour of nthcdr for negative N is well-established and turns out = to be somewhat useful in practice. I didn't know that. We specifically undocumented it in 2013, as it turns out (3e6b67c9b7230bf10219082d9215d9617a33715e): 2013-08-13 Glenn Morris =09* lists.texi (List Elements): =09Undocument behavior of nth and nthcdr with n < 0. (Bug#15059) I agree with the statement in that bug thread: All hope is lost. We can't fix it and it is broken, and now we're stuck with permanent harm. The only thing it's good for now is to serve as a cautionary tale. >> If it were merely undocumented, I might agree, but the current behavior >> doesn't match the documentation, > > Yes, the manual and doc strings could certainly be improved. By reverting that commit? >> because taking cdr -1 times is >> obviously an impossible thing to do. > > Well now, we could define > > (nthcdr N L) =3D (cons nil (nthcdr (1+ N) L) > > for N<0. (No, we shouldn't.) As I said, that's defining 0/0 to be 17 because it's A solution to 0 * x =3D 0. We don't, because we want the unique solution. >> This isn't about performance. > > Of course it's about performance. In some respect it always is! In the spirit of contradicting in the strongest possible way, how about we make it infloop? It'd never return an unexpected value or throw an unexpected error, then, and it matches the while (count--) x =3D Fcdr (x) idea. Pip