Re: Negative nth index

[Pip Cet]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 25 dec. 2024 kl. 11.56 skrev Pip Cet <pipcet@protonmail.com>:
>
>> 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  <rgm@gnu.org>

        * lists.texi (List Elements):
        Undocument 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) = (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
= 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 = Fcdr (x)
idea.

Pip