Add `list.min` function

[Eosis]

There is currently a list.max function in the stdlib, but not a list.min function.

This can lead to clunky code when list.max is used to retrieve the minimum value from a list.

let min = list.max([1, 2, 3], order.reverse(int.compare))

I suggest also adding list.min to both avoid this clunkiness and make the stdlib less surprising (I was certainly surprised there was no list.min when there was a list.max). It seems a bit inconsistent to have a max and not a min, and is common in various other equivalent libraries that provide a max.

Rust max min
Erlang max min
Haskell max min

There is a PR with a trivial implementation.

[lpil]

Could be good, though the order.reverse function you've highlighted there does seem to do the job well already. Is the problem that people are getting stuck or confused, or is more of a stylistic matter?

RE consistency, having negated versions of all the various functions isn't something I'd like to do. filter->reject, etc.

[Eosis]

Is the problem that people are getting stuck or confused, or is more of a stylistic matter?

I think it is a bit of both. While doing Advent of Code, I needed the min int of a list. I knew that max existed, so I merrily typed list.min and got a compiler error. I then needed to search around the docs to understand the Order module and the reverse function, and then re-use list.max with that extra info. It felt much harder than I expected and a bit of a hack.

Could be good, though the order.reverse function you've highlighted there does seem to do the job well already.

It works, but I find it clunky to write, harder to read, and takes a few more steps (as described above) to understand compared to list.min([1,2,3], int.compare), which I feel is quite transparent. I think Gleam is already spending some "weirdness points" in needing to pass in the explicit ordering function (compared to langs in previous post), and needing to think of mins as abstract maxes is just compounding on that.

RE consistency, having negated versions of all the various functions isn't something I'd like to do. filter->reject, etc

This is an interesting point, though I would probably lean on the conventions of other libraries, which don't have a filter and a reject but do have both a max and a min. That is the case for all the examples I gave in the previous comment.

[lpil]

Makes sense, thank you.

I would probably lean on the conventions of other libraries, which don't have a filter and a reject but do have both a max and a min.

Quite a lot of languages and libraries have negated filter and such, so there's not a clear convention overall.

[jimutt]

I would also appreciate the presence of a list.min, having gone through the same chain of thoughts and actions as @Eosis. 🙂 I get the whole "having negated versions of all the various functions isn't something I'd like to do" reasoning though, makes sense. But my personal angle and intuition, of course based mostly on subjective experiences from a subset of other programming languages and libraries, is similar to that of Eosis: Having max and min for list wouldn't by extension increase my expectation to find a reject.

[alhassy]

1. I'd like to expand on this thought, for anyone who's not so certain that this idea applies to min & max.

having negated versions of all the various functions isn't something I'd like to do.

Just as reject and filter are related by applying Boolean negation, min and max are related via De Morgan's Laws for arithmetic:

  -(x max y)  =  -x min -y
  -(x min y)  =  -x max -y

2. Personally, I've always liked how Common Lisp's library was massive and had everything I ever needed.

However, afaict, Gleam's philosophy is KISS, Keep it super simple, and so ideally there aren't multiple ways to get the same thing done using just the language and the std lib; and otherwise, to use third-party libraries.

3. An upside of omitting min is it lets users think about the problem they're solving from the converse direction:

   x min y = x if and only if y = x max y

4. There are lots of surprising things in the language, I don't think this is a deal breaker.

• No runtime exceptions
• x / 0 = 0
• No way to recover from panic, unless you invest in supervisors (maybe?)
• Field punning requires a trailing :, unlike JS
• There are two additions on numbers, + and +.

5. I'd personally prefer there be a min, but I'd also prefer a lot of things that likely are not the Gleam way.

[jkbrinso]

I agree that list.min would be useful and not inconsistent, especially for novices.

list.min might be, in some rhetorical sense, the "opposite" of list.max, but it is not a "negated" list.max or the opposite of list.max in the same sense that filter and reject are negated versions of one another. Filter returns a set of things, and reject returns the set of all things not included in filter. One can easily derive reject putting an exclamation point in front of the filter function call.

But list.min and list.max are two different operations that do two different things, and "negating" one does not produce the other, much like list.first and list.last, both of which are included and which do different things. Why do we have both list.first and list.last? See also fold and fold_right. Why not just reverse the list and fold?

For some novices, the solution of doing order. reverse() is not obvious at all. In fact, I might have tried to implement this using a reverse sort and list.first, which I imagine is less efficient and also requires dealing with the Result. Not having list.min, when we have fold_right and list.last, feels internally inconsistent and like needless friction for functional programming novices. order.reverse is definitely not as intuitive as a simple exclamation point before a boolean filter function.