[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40570: [PATCH] Alias cl-subseq to seq-subseq, define gv-setter in th
From: |
Štěpán Němec |
Subject: |
bug#40570: [PATCH] Alias cl-subseq to seq-subseq, define gv-setter in the latter |
Date: |
Sun, 12 Apr 2020 19:16:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
On Sun, 12 Apr 2020 12:18:15 -0400
Stefan Monnier wrote:
>> The definition was moved in
>>
>> 2019-10-27T13:25:00-04:00!monnier@iro.umontreal.ca
>> 0e4dd67aae (* lisp/emacs-lisp/seq.el: Don't require cl-lib.)
>>
>> already, but not the gv-setter declaration, so 'setf' worked with
>> 'cl-subseq', but not with 'seq-subseq'.
>
> Indeed, when I made the move I just wanted to change the implementation
> but not the featureset (AFAIK seq-subseq never supported `setf`).
>
> So this bug report is fundamentally a feature request: make `seq-subseq`
> into a (gv) generalized variable.
>
>> --- a/lisp/emacs-lisp/seq.el
>> +++ b/lisp/emacs-lisp/seq.el
>> @@ -154,6 +154,11 @@ seq-subseq
>> START or END is negative, it counts from the end. Signal an
>> error if START or END are outside of the sequence (i.e too large
>> if positive or too small if negative)."
>> + (declare (gv-setter
>> + (lambda (new)
>> + (macroexp-let2 nil new new
>> + `(progn (cl-replace ,sequence ,new :start1 ,start :end1 ,end)
>> + ,new)))))
>
> The main purpose of the move was to reverse the order of dependency so
> that `cl-lib` would depend on `seq` rather than the reverse.
> This implies that `seq` shouldn't use `cl-lib`. The above `cl-replace`
> is hence problematic.
Oh, right... sorry.
> Another issue is that `seq-subseq` is a generic function, so its
> gv-setter should also use generic functions so that it can also be made
> to work on other sequence types than the predefined ones.
>
> IOW we should probably introduce a new `seq` generic function which does
> something similar to `cl-replace`, then make `seq-subseq` use it in its
> gv-setter, and ideally also make `cl-replace` use it ;-)
Indeed. The definition of `cl-replace' looks like not for the faint of
heart, also a lot of that impression comes from all the cl- prefixed
args and variables. Is that just an artifact of some automatic
replacement process, or is there a reason those have to have the cl-
prefix? Or a conspiracy to make cl-*.el even more impenetrable?
--
Štěpán