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

Previous Next

To reply to this bug, email your comments to 68863 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Add support for using setf with seq-subseq
Date: Thu, 01 Feb 2024 03:31:10 +0000

[Message part 1 (text/plain, inline)]

Hello,

This patch adds support for using `seq-subseq` with `setf`, as in

     ;; => [0 1 2 10 11]
     (let ((seq (vector 0 1 2 3 4)))
       (setf (seq-subseq seq -2) (list 10 11 12 13 14))
       seq)

The patch adds a generic version which uses the existing `setf` support 
of `seq-elt` and a specialized version for modifying lists.  Both 
versions use `seq-do` to map a function over the values that should 
replace the values in the modified sequence.

To avoid modifying more values than specified, that modifying function 
uses a `when` condition. I'm not sure of a good way to stop `seq-do` 
early when we know that it can stop calling the modifying function. 
Normally, I would use `cl-block` and `cl-return`. Is it OK to use those 
features in `seq.el`? If not, is it worth adding something like a 
`seq-map-while` or a `seq-do-while`?

Thank you.

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

Message #8 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: 68863 <at> debbugs.gnu.org
Cc: Nicolas Petton <nicolas <at> petton.fr>
Subject: [PATCH] Add support for using setf with seq-subseq
Date: Sun, 04 Feb 2024 18:33:14 +0000

[Message part 1 (text/plain, inline)]

Hello,

I've added the maintainers e-mail address to the discussion and have 
added "[PATCH]" to the subject to make it more clear that there is a 
patch file attached.

I tested a version that uses a `seq-map-while`, but it only made a 
difference when the sequence of values to copy to the existing sequence 
was longer than 100 elements, which I would guess is a less common use case.

Thank you,
Earl

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

Message #11 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Okamsn <okamsn <at> protonmail.com>, Nicolas Petton <nicolas <at> petton.fr>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 68863 <at> debbugs.gnu.org
Subject: Re: bug#68863: Add support for using setf with seq-subseq
Date: Thu, 08 Feb 2024 13:39:48 +0200

> Date: Thu, 01 Feb 2024 03:31:10 +0000
> From:  Okamsn via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> This patch adds support for using `seq-subseq` with `setf`, as in
> 
>      ;; => [0 1 2 10 11]
>      (let ((seq (vector 0 1 2 3 4)))
>        (setf (seq-subseq seq -2) (list 10 11 12 13 14))
>        seq)
> 
> The patch adds a generic version which uses the existing `setf` support 
> of `seq-elt` and a specialized version for modifying lists.  Both 
> versions use `seq-do` to map a function over the values that should 
> replace the values in the modified sequence.
> 
> To avoid modifying more values than specified, that modifying function 
> uses a `when` condition. I'm not sure of a good way to stop `seq-do` 
> early when we know that it can stop calling the modifying function. 
> Normally, I would use `cl-block` and `cl-return`. Is it OK to use those 
> features in `seq.el`? If not, is it worth adding something like a 
> `seq-map-while` or a `seq-do-while`?

Thanks.

Nicolas, Stefan: any comments?  seq.el is preloaded, so we should
consider whether this addition is important enough to have it in seq
or elsewhere, if we think it's useful.

Message #14 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Okamsn <okamsn <at> protonmail.com>, 68863 <at> debbugs.gnu.org,
 Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#68863: Add support for using setf with seq-subseq
Date: Thu, 08 Feb 2024 09:25:51 -0500

>> This patch adds support for using `seq-subseq` with `setf`, as in
>> 
>>      ;; => [0 1 2 10 11]
>>      (let ((seq (vector 0 1 2 3 4)))
>>        (setf (seq-subseq seq -2) (list 10 11 12 13 14))
>>        seq)
>> 
>> The patch adds a generic version which uses the existing `setf` support 
>> of `seq-elt` and a specialized version for modifying lists.  Both 
>> versions use `seq-do` to map a function over the values that should 
>> replace the values in the modified sequence.
> Nicolas, Stefan: any comments?

Fine by me.

>> To avoid modifying more values than specified, that modifying function 
>> uses a `when` condition. I'm not sure of a good way to stop `seq-do` 
>> early when we know that it can stop calling the modifying function. 
>> Normally, I would use `cl-block` and `cl-return`. Is it OK to use those 
>> features in `seq.el`? If not, is it worth adding something like a 
>> `seq-map-while` or a `seq-do-while`?

`seq.el` is used by some parts of the implementation of `cl-lib`, so
the use of `cl-lib` risks introducing a circular dependency.  Maybe using
`cl-block/return` would be OK, but I wouldn't be surprised if it causes
bootstrap trouble.  You can use catch/throw, OTOH.


        Stefan

Message #17 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 68863 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#68863: Add support for using setf with seq-subseq
Date: Fri, 09 Feb 2024 03:54:32 +0000

[Message part 1 (text/plain, inline)]

Stefan Monnier wrote:
>>> To avoid modifying more values than specified, that modifying function
>>> uses a `when` condition. I'm not sure of a good way to stop `seq-do`
>>> early when we know that it can stop calling the modifying function.
>>> Normally, I would use `cl-block` and `cl-return`. Is it OK to use those
>>> features in `seq.el`? If not, is it worth adding something like a
>>> `seq-map-while` or a `seq-do-while`?
> 
> `seq.el` is used by some parts of the implementation of `cl-lib`, so
> the use of `cl-lib` risks introducing a circular dependency.  Maybe using
> `cl-block/return` would be OK, but I wouldn't be surprised if it causes
> bootstrap trouble.  You can use catch/throw, OTOH.
> 
> 
>          Stefan
> 

Attached is an updated version using `catch` and `throw`. Thank you for 
pointing those out to me. The patch is also changed to signal 
`args-out-of-range` for the start and end indexes to be more like 
`seq-subseq`.

How does it look?

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

Message #20 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 68863 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#68863: Add support for using setf with seq-subseq
Date: Wed, 14 Feb 2024 02:50:29 +0000

Okamsn wrote:
> Stefan Monnier wrote:
>>>> To avoid modifying more values than specified, that modifying function
>>>> uses a `when` condition. I'm not sure of a good way to stop `seq-do`
>>>> early when we know that it can stop calling the modifying function.
>>>> Normally, I would use `cl-block` and `cl-return`. Is it OK to use those
>>>> features in `seq.el`? If not, is it worth adding something like a
>>>> `seq-map-while` or a `seq-do-while`?
>>
>> `seq.el` is used by some parts of the implementation of `cl-lib`, so
>> the use of `cl-lib` risks introducing a circular dependency.  Maybe using
>> `cl-block/return` would be OK, but I wouldn't be surprised if it causes
>> bootstrap trouble.  You can use catch/throw, OTOH.
>>
>>
>>           Stefan
>>
> 
> Attached is an updated version using `catch` and `throw`. Thank you for
> pointing those out to me. The patch is also changed to signal
> `args-out-of-range` for the start and end indexes to be more like
> `seq-subseq`.
> 
> How does it look?

Hello,

After testing it more, I see that what I've written does not work as I 
expected in the case

(let ((v    (vector (vector 0 1)
                     (vector 2 3)
                     (vector 4 5))))
   (setf (seq-subseq (seq-subseq (elt v 0) 0) 0)
         [10])
   v)

in which I would expect it to replace the first element of the first 
sub-vector with 10. I will take more time to continue working on this.

Thank you for your patience.

Message #23 received at 68863 <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 68863 <at> debbugs.gnu.org, Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#68863: Add support for using setf with seq-subseq
Date: Thu, 18 Apr 2024 02:54:46 +0000

[Message part 1 (text/plain, inline)]

Okamsn wrote:
> Hello,
> 
> After testing it more, I see that what I've written does not work as I
> expected in the case
> 
> (let ((v    (vector (vector 0 1)
>                       (vector 2 3)
>                       (vector 4 5))))
>     (setf (seq-subseq (seq-subseq (elt v 0) 0) 0)
>           [10])
>     v)
> 
> in which I would expect it to replace the first element of the first
> sub-vector with 10. I will take more time to continue working on this.
> 
> Thank you for your patience.
> 
> 

Hello,

I found a way to work with subplaces, like in the example in my previous 
e-mail message. Instead of creating the generic feature `(setf 
seq-subseq)` like what is done for `seq-elt`, I created a generic 
function `seq-replace`, which is used in a new `gv-expander` for 
`seq-subseq`. This way of doing it is like what is done for `substring`, 
which has the behavior that I wanted.

What do you think about this approach?

Thank you.

[v3-0001-Add-seq-replace-and-setf-support-for-seq-subseq.patch (text/x-patch, attachment)]

Previous Next

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