Open ckp95 opened 2 years ago
As long as these additions are not done to system.nim
, I have no real objections. However, here is an idea: Instead of adding more and more things to sequtils
and algorithm
, let's have algorithms in their own modules:
sort.nim
, map.nim
, fold.nim
, minmax.nim
, ...
(Related to Nim v2.)
you can already do
type AbsInt = distinct int
proc `<=`(a, b: AbsInt): bool = abs(int(a)) <= abs(int(b))
echo int(min(AbsInt(-10), AbsInt(-12)))
I like this very much. Recently while just playing around with something I did
data.sortedByIt(criterion it)[0]
(when I needed just data.minByIt(criterion it)
) because I was lazy.
maxIt
shouldn't create a closure, it should inline everything, that's the main draw of mapIt/foldIt and friends.
Regarding Araq proposal I would classify like this:
I want this.
I forgot I made this RFC because I haven't used Nim for a while. But I see that Nim 2 is out now so I'll take another look at it and try to make a PR for these functions soon(tm).
you can already do
type AbsInt = distinct int proc `<=`(a, b: AbsInt): bool = abs(int(a)) <= abs(int(b)) echo int(min(AbsInt(-10), AbsInt(-12)))
Yeah I guess, but having to define a new type and a <
proc is a hassle. It's overkill when all I usually want is to make an ad-hoc / one-off criterion. Why do it in three lines when you could do it in one?
Abstract
I propose to allow the
max
andmin
procs to take an additional argument, which specifies the criterion by which the comparisons are made. This could either be a single-argument procedure, or anit
expression (similar tomapIt
and friends).Motivation
It is fairly common to want to get the maximum and minimum of a sequence of
T
, but by a different criterion than the usual<
defined forT
(or where<
isn't even defined forT
). Examples:The
algorithm
module in the standard library already provides an analogous functionality for thesort
family of functions: you can provide acmp
argument, or usesortedByIt
. I suppose a third option could be to allowmax
andmin
to take acmp
function, although personally I find thecmp
style to be fiddly in this context.Other languages (e.g. Python) also allow you to pass a function to
max
andmin
.Description
The
max
implemention in proc style:In
it
style:proc or
it
?I'm not sure whether the criterion should be specified as a proc, or in
it
style, or whether to have both coexisting like is done withmap
andmapIt
. Personally I prefer the proc style, but either or both are fine and have precedent. Thoughts?Examples
Procedure way:
it
way:Also the two-argument forms (i.e. not on an
openArray
) would allow for a criterion argument:Other Things
While I'm on the subject, I thought of some other existing procs that might benefit from taking a criterion argument, and some new procs that could be added to
sequtils
on the same theme.The
maxIndex
andminIndex
procs insequtils
are the obvious next step (it
versions omitted for brevity):(On an unrelated note, could we also add create
argmax
andargmin
as aliases formaxIndex
andminIndex
? I thought the stdlib didn't have them for ages, until I noticedmaxIndex
andminIndex
by accident while reading thesequtils
docs.)The
find
function could have variants which take a predicate argument:It also seems useful to have
first
andlast
procs insequtils
:(The return type should probably be
Option[T]
because the predicate might never be satisfied.)Backward Incompatibility
This should not cause any backward-incompatible changes, since you would still be able to use
max
andmin
in the same way as before just by not passing in the criterion argument. These would be defined as additional versions ofmax
andmin
, with different argument signatures, not modifying the existing definitions.