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

Sean Whitton <[email protected]> writes:

> Philip Kaludercic [08/Aug  7:59pm GMT] wrote:
>> Finding the maximal or minimal element of a list according to some
>> comparative metric has been something I have run into multiple times
>> (just now, I was trying to find the newest version of a package
>> according to `version-list-<'), but always implemented by hand.  I would
>> like to propose extending the existing seq-min and seq-max functions
>> with an optional argument, along the lines of `sort':
>
> 'sort' used to be just (sort SEQ LESSP) but now it has another calling
> convention that uses CL-style keyword arguments.
>
> To avoid this happening again, let's use (sequence &key lessp) right
> away -- it's already a cl-defgeneric anyway.
>
> Code looks good, interesting approach with the eval-when-compile
> (I would have used a cl-loop since it doesn't seem like it's truly a
> reduction, but what you have is fine).

Why isn't this a reduction?

Sean Whitton <[email protected]> writes:

> Sean Whitton [09/Aug 11:50am +01] wrote:
>> Code looks good, interesting approach with the eval-when-compile
>> (I would have used a cl-loop since it doesn't seem like it's truly a
>> reduction, but what you have is fine).
>
> Well, a while loop, probably, given seq.el is preloaded.

Hmm, but that would amount to just manually looping over the sequence
(seq-length seq) many times and comparing the current best element with
that in (seq-elt seq i)?