bug#68863: Add support for using setf with seq-subseq

[Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Okamsn <okamsn@protonmail.com> writes:

> Here is what I have thought:
>
> 1. The setter should be consistent for different kinds of sequences. My
> understanding is that arrays cannot be extended, so I think that it
> should not be able to extend lists either. I think that something like a
> non-destructive `seq-replace` or a non-destructive `seq-splice` is a
> separate feature.

[...]

> 3. The setter should not modify the sequence containing the replacement
> values. The manual states: "All functions defined in this library are
> free of side-effects; i.e., they do not modify any sequence (list,
> vector, or string) that you pass as an argument." I think that it makes
> sense for the setter to modify the target sequence, because `setf` is
> used to set places to values, but I think that it would be unexpected to
> modify the sequence of replacement values and that it would be contrary
> to what the manual states and how the other features behave.

That's a bit of a contradiction, since when using your patch we do
modify the original sequence.  That's a reason why your suggestion
doesn't fit that well into the current seq.el.

But The main question for me is: do we want something like you suggest
in seq.el.  And, if we do, should we then provide this functionality as
a generalized variable.  And if we do offer and advertise this
explicitly, it must be implemented as efficient as possible (which is
not the case now).

But I'm stuck with the first question.  And my gut feeling is a clear
"No".  First, I would not provide this as gv but as a normal function.
There is no necessity to go the gv way.

Second, it doesn't fit into seq.el for the reason you gave: the library
promises not to modify sequences.  This is not cut in stone, of course.


> I will try to find uses of `cl-replace` and maybe uses of `append` and
> `nconc` for examples. Also, I have attached a version of the patch that
> does not compute the length of the list unless needed.

I'm mostly interested in real-life examples where your patch would lead
to simpler, better understandable and better maintainable code; and I
think Stefan, too.

That you need such a functionality for your own code counts but is not
enough of its own.  You surely could modify your macro to do what you
want without changing Emacs.


Michael.