Actual working solution I'm using for now:

(defwidget select_ranged [map value ?template]
  (box
    (for entry in map
      (literal :visible {
                         (matches(entry[0], "-?\\d+\\.\\.-?\\d+") && (search(entry[0], "-?\\d+")[0] == "null" ? 0 : search(entry[0], "-?\\d+")[0]) <= value && (search(entry[0], "-?\\d+")[1] == "null" ? 0 : search(entry[0], "-?\\d+")[1]) > value) ||
                         (matches(entry[0], "-?\\d+\\.\\.=-?\\d+") && (search(entry[0], "-?\\d+")[0] == "null" ? 0 : search(entry[0], "-?\\d+")[0]) <= value && (search(entry[0], "-?\\d+")[1] == "null" ? 0 : search(entry[0], "-?\\d+")[1]) >= value) ||
                         (matches(entry[0], "-?\\d+\\.\\.$") && (search(entry[0], "-?\\d+")[0] == "null" ? 0 : search(entry[0], "-?\\d+")[0]) <= value) ||
                         (matches(entry[0], "^\\.\\.-?\\d+") && (search(entry[0], "-?\\d+")[0] == "null" ? 0 : search(entry[0], "-?\\d+")[0]) > value) ||
                         (matches(entry[0], "^\\.\\.=-?\\d+") && (search(entry[0], "-?\\d+")[0] == "null" ? 0 : search(entry[0], "-?\\d+")[0]) >= value)}
             :content {template == ""? entry[1] : replace(template, "\\{}", entry[1])}))))

The template is there as it is not a function but a widget and I therefor cannot wrap the returned value in another widget otherwise.

I implemented a proof of concept here: #628

This could be extended to support non-numeric ranges/values as well.
I imagine a set of conditions that could work like so:

• start?..(=?end)? a range (open, exclusive/inclusive) proposed syntax matches rusts
• (==|(<|>)=?) value compares the input as lhs using the operator to the value (maybe allow both orders, i.e. value <= as well)
• /regex/ compares the input to the regex
• condition_a (&&|\|\|) condition_b matches if the combined condition is true
• () parenthesis can be used for precedence

Alternative syntaxes

• [start,end], [start,end_exclusive), [start, end_exclusive[ or start - end
• {} > 5 to mark where to place the compared value
• matches("regex")
• use , for and, and ; for or

I like this idea! In the long run, i wonder if it would make sense to have a case {x} of {pattern} => {value} {pattern} {value} ... syntax.

I like this idea! In the long run, i wonder if it would make sense to have a case {x} of {pattern} => {value} {pattern} {value} ... syntax.

Would be interesting to consider syntax options. I tried to do this without adding a new language feature, but having actual syntax for this would maybe also help for readability.

Rust-like match would also be an option

match value {
  == "value" => smth,
  /regex/ => smth,
  0..=10 => smth
}

This kind of plays into a bigger problem I have with the current simplexpr syntax and language... I kinda of really want to have lambdas, but simultaneously feel like it's already grown wayyy further than I should have let it, and adding higher order functions would make it even worse. I get that this sort of feature would be useful, but,... I'll be very careful adding any sort of magic syntax like this, for now, in hopes of finding a good general solution in the future

Yeah that's why I proposed the purely string based function that would not be adding a new syntax to the simpleexpr language.

I now added a function jq that allows jq-style json processing, and should also support the string processing functionality there, through the slice operation .[2:10]