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

[Matúš Goljer]

> 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.

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.

>>> 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.

-- 
Best regards,
  Matúš Goljer