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

[Philip Kaludercic <philipk@posteo.net>]

Augusto Stoffel <arstoffel@gmail.com> writes:

> Maybe it's more useful to allow negative arguments in seq-elt?  Saying
> (seq-elt seq -1) isn't much more effort than (seq-last seq).
>
> On Tue, 14 Mar 2023 at 16:14, Philip Kaludercic wrote:
>
>>> 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).
>
> It would be good to look systematically at what errors seq.el can
> signal.  But it also seems that in practice the main value of seq.el is
> to provide a bunch of handy functions rather than allowing you to work
> with a sequence whose type you don't know.

I don't think the two are necessarily different issues.  Using seq might
incur a dispatch overhead, but you get the advantage that your code is
less bound to a specific data structure and is therefore easier to
adjust later on because you rely on the abstract behaviour instead of a
concrete structure.

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

>> Maybe it's more useful to allow negative arguments in seq-elt?  Saying
>> (seq-elt seq -1) isn't much more effort than (seq-last seq).
>
> I'm personally a bit ambiguous about negative indices.  It's nice for
> those one liners when you need them, but they are quite confusing
> especially if you switch between languages and they all implement them a
> bit differently.

The only language I am really familiar with is python, and what that
effectively does is (mod i (length n)), what do other languages do?

> Sometimes having simple semantics of "last item" is better for
> understanding the code 6 months down the line or when just skimming
> through.
>
> But of course we can have both.  Emacs itself has `car` but `nth 0` also
> works.

True.

>>>> 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).
>>
>> It would be good to look systematically at what errors seq.el can
>> signal.  But it also seems that in practice the main value of seq.el is
>> to provide a bunch of handy functions rather than allowing you to work
>> with a sequence whose type you don't know.
>
> Yea, this has been my experience as well.  Usually I know what the
> sequence is, but seq provides a nice interface to not have to *remember*
> how to do what I need.  Just seq-do it and it will work somehow.

Another thing that should be kept in mind that sequences can be streams
(as provided by stream.el), and there doesn't have to be a final
element.

-- 
Philip Kaludercic