Re: [PATCH] seq.el: add seq-last for symmetry with seq-first

[Philip Kaludercic]

Matúš Goljer <matus.goljer@gmail.com> writes:

>> Wouldn't it make sense to add a specialised implementation for lists, to
>> avoid recusing the list twice.
>
> I can turn it into defgeneric with default implementation same as what I
> provided and special instance for a list, that makes sense.  Although I
> wonder what the performance impact is of the dispatch vs iterating a
> list /shrug.

That would be worth investigating, but considering that your proposed
implementation would already have two dispatches (seq-elt and
seq-length), I don't think this will be much worse, especially when the
sequence becomes longer.

>> A thing I notice is that seq-first is not consistent on the way it
>> behaves if the sequence is empty.
>>
>>         (seq-first '()) ;=> nil
>>
>> while
>>
>>         (seq-first [])
>>
>> raises an error.  seq-last would have the same issue for vectors, except
>> that it would attempt to index the position -1, which might be
>> confusing?
>
> I think for lists it should behave as `nth` or `elt`, so it gives nil.

But why?  Wouldn't that be a leaky abstraction, since the behaviour
doesn't consistently abstract over the concrete sequence types?  If code
doesn't want to worry about what sequence is being used, then it has to
manually check the return value or if a signal was raised, depending on
the type of the argument to seq-last (which is to ignore the issue that
we cannot distinguish between (seq-first '()) and (seq-first '(nil)),
the same also being the case for seq-last).

> I agree that the error with -1 for vector might be confusing.  Should we
> instead raise our own (seq) error for empty vector with seq-first and
> seq-last?  Not sure what would be the best way.

I believe this would always be better, even for seq-first, though it
might be that too late for that?

> I should also add some tests, I've noticed there was a test file for
> seq.  Should I resubmit this patch with the feedback incorporated to
> bug-gnu-emacs@gnu.org instead?  I'm not sure if emacs-devel is the
> place, sorry T_T.

IIRC patches should be sent to bug-gnu-emacs@gnu.org, but emacs-devel is
also acceptable if there is a need for discussion.  I think the points I
raised above would be worth a general discussion on how seq is to be
used, which is not the matter of a single bug report.