Jonathan (Jun 19 2026 at 11:42): Jonathan (Jun 19 2026 at 11:42):Thinking about getting the remaining list sort builtins done. We have sort_with (requiring a 2-ary comparison function) but not sort (requiring just a sortable element) or sort_by (where a key function is supplied). As per #7006 there's also the reversed variants.
I just thought I'd touch on the naming first. For some comparison ( :drum: ), names of sorting functions in order of simple sort, sort using key function, and sort using comparison function (excluding languages that use variable arity or default arguments, like python with sort(key=f))
Rust: Names these sort, sort_by_key, and sort_by
Haskell: sort, sortBy, and sortOn
Elm: sort, sortBy, sortWith
Kotlin: sorted, sortedBy,sortedWith
Currently Roc may buck the trend a little by naming the comparison sort I got muddled, it's consistent.sort_with but it's a bit of a mixed bag overall.
Jonathan (Jun 19 2026 at 11:45):For the basic sort function, does it make sense to only restrict the element to the necessary functions:
sort : List(a) where [ a.is_eq ..., a.is_lt ]
or to also include is_gt even if it isn't necessary?
Jonathan (Jun 19 2026 at 11:48):@Luke Boswell sorry, put this in the wrong topic, would you mind moving it to ideas if that's ok please?
Jonathan (Jun 19 2026 at 12:10):For sort_by, I'm unsure whether to limit the number of times the key function is called, for instance by allocating a list with the key function result zipped alongside, or call the key function whenever required. The benefit of each would depend on the default sorting algorithm, but also the key function and list length, so perhaps there's potential for a sort_by_cached_key too?
Anton (Jun 19 2026 at 12:42):Jonathan said:
For the basic sort function, does it make sense to only restrict the element to the necessary functions:
sort : List(a) where [ a.is_eq ..., a.is_lt ]
or to also include is_gt even if it isn't necessary?
I would go with only the necessary functions.
Anton (Jun 19 2026 at 12:45):Jonathan said:
For sort_by, I'm unsure whether to limit the number of times the key function is called, for instance by allocating a list with the key function result zipped alongside, or call the key function whenever required. The benefit of each would depend on the default sorting algorithm, but also the key function and list length, so perhaps there's potential for a sort_by_cached_key too?
Let's start with the simple approach, make sure it's very robust (correct and bug-free) and improve perf later.
Jonathan (Jun 19 2026 at 13:39):Just to clarify for myself the prior guidance on testing builtins ( ) - snapshot coverage should be mostly sufficient, but when is the distinct need for low_level tests?
Anton (Jun 19 2026 at 14:06):I believe the convention is that if the function is implemented purely in Roc we just do snapshots, and if Builtin.roc only contains the annotation of the function we do low_level tests.
Jonathan (Jun 19 2026 at 14:07):Ah, makes sense :face_palm: thank you
Brendan Hansknecht (Jun 19 2026 at 19:07):Roc uses fluxsort, just for reference
Jonathan (Jun 19 2026 at 23:08):Ah, I missed that. It just hasn't been wired through to the roc builtins yet? Currently I think there's just a quicksort implemented in Roc for sort_with.
Richard Feldman (Jun 19 2026 at 23:10):yeah the new compiler has a very placeholder implementation at the moment :sweat_smile:
Jonathan (Jun 19 2026 at 23:11):Ok, once we cross the Roc/Zig boundary I get a bit out of my depth to be honest :smile:
Jonathan (Jun 19 2026 at 23:12):I suppose I was just planning on completing the very placeholder implementation but better to get it done properly
Richard Feldman (Jun 19 2026 at 23:19):that's fine!
Richard Feldman (Jun 19 2026 at 23:19):progress is good :smiley:
Last updated: Jul 23 2026 at 13:15 UTC