bug#40570: [PATCH] Alias cl-subseq to seq-subseq, define gv-setter in the latter

["Štěpán Němec" <stepnem@gmail.com>]

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