bug#81581: [PATCH 1/1] Add a LESSP argument to 'seq-min' and 'seq-max'

> From: Philip Kaludercic <[email protected]>
> Cc: Stefan Monnier <[email protected]>,  Nicolas Petton
>  <[email protected]>,  [email protected]
> Date: Sun, 09 Aug 2026 07:28:27 +0000
> 
> Eli Zaretskii <[email protected]> writes:
> 
> >> From: Philip Kaludercic <[email protected]>
> >> Date: Sat, 08 Aug 2026 19:59:57 +0000
> >> 
> >> -(cl-defgeneric seq-min (sequence)
> >> +(cl-defgeneric seq-min (sequence &optional lessp)
> >>    "Return the smallest element of SEQUENCE.
> >> -SEQUENCE must be a sequence of numbers or markers."
> >> -  (apply #'min (seq-into sequence 'list)))
> >> +Values are compared according to the optional parameter LESSP, which
> >> +defaults to `value<'."
> >> +  (unless lessp (setq lessp #'value<))
> >> +  (let ((fresh (eval-when-compile (make-symbol "fresh"))))
> >> +    (seq-reduce
> >> +     (lambda (acc elt)
> >> +       (cond
> >> +        ((eq acc fresh) elt)
> >> +        ((funcall lessp acc elt) acc)
> >> +        (t elt)))
> >> +     sequence
> >> +     fresh)))
> >
> > How about optimizing for the default nil value of LESSP?  The original
> > implementation should be faster than the modified one, so how about
> > keeping the original performance for those who don't need a fancy
> > comparison function?
> 
> Or did I misunderstand you, and you are advocating for a case
> distinction on LESSP, and dispatch to `min' and `max' if LESSP is `<`
> (instead of nil)?

Yes, that's what I meant.

I'll also ask why shouldn't the default be '<' anyway, to preserve
backward compatibility?