GNU bug report logs - #68863
Add support for using setf with seq-subseq

Previous Next

Package: emacs;

Reported by: Okamsn <okamsn <at> protonmail.com>

Date: Thu, 1 Feb 2024 03:32:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Okamsn <okamsn <at> protonmail.com>
To: michael_heerdegen <at> web.de, 68863 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, nicolas <at> petton.fr, monnier <at> iro.umontreal.ca
Subject: bug#68863: Add support for using setf with seq-subseq
Date: Tue, 14 May 2024 12:47:14 +0000
[Message part 1 (text/plain, inline)]
Michael Heerdegen wrote:
> Hello again,
> 
> There is a second point I want to hint at/ discuss:
> 
> Some time ago we have removed lots of or even the majority of the
> so far implemented generalized variables.
> 
> The main criteria were: are they useful, and is the semantics clear.  We
> should think about whether this is the case here.
> 
> For `seq-subseq' the semantics is not completely unambiguous.  For
> example, the setter could exchange a subsequence - but also simply
> insert an additional piece, creating a longer sequence.  Both operations
> can be useful.
> 
> Likewise, when an index (e.g. the starting position) is going beyond the
> end of a sequence, Emacs could raise an error, or provide functionality
> to append to the existing sequence.  Again, both kinds of behavior could
> make sense in different situations.
> 
> Finally, the question of whether the operation is destructive, or which
> of the involved sequences are reused, is not trivial.
> 
> Any thoughts about these points?  Is this generalized variable useful
> enough to make this acceptable?  Which kind of implementation do we
> prefer then?
> 
> 
> Michael.

Hello,

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.

2. The setter should be consistent with how `seq-subseq` raises errors. 
`seq-subseq` raises an error if a given index is greater than the 
sequence's length, so the setter should too.

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.

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.

Thank you.
[v4-0001-Add-setf-support-for-seq-subseq.patch (text/x-patch, attachment)]

This bug report was last modified 107 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.