Comparisons for number, string, array, and record

[jeremyschlatter]

Hello! This is my first PR to Nickel.

I was writing some Nickel configuration today and found myself wanting string comparisons. I found this open issue, and decided to take a shot at it.

Resolves #1030

[yannham]

Thanks a lot for taking this on! It looks pretty good, beside a few secondary comments.

[yannham]

I feel like the name of this function is not very descriptive of what it does. I don't have a great inspiration right now, and it is a bit hard to describe as it's pretty abstract. We'll bikeshed that in the weekly meeting tomorrow and I'll report back here.

[jeremyschlatter]

Yeah, it's not obvious to me what to call this. For what it's worth, Haskell has a function on that is very similar:

(b -> b -> c) -> (a -> b) -> a -> a -> c

The Nickel function here is the same as Haskell's on except:

• the arguments are flipped
• a is specialized to { _ : b }
• (a -> b) is specialized to accessing a named field

Curious to hear how the bikeshedding goes.

[yannham]

At first I thought we would need to do something unicode-aware, because Nickel uses everywhere grapheme clusters as its unit of string characters. However, the Rust comparison is just comparing byte by byte lexicographically. I guess doing that, or first splitting by grapheme clusters, and then comparing cluster by cluster (using the normal string comparison) is entirely equivalent, so this is fine.

[jeremyschlatter]

Thanks @yannham! I made the changes you suggested.

[yannham]

With 4th of July and unrelated stuff, the weekly was rather empty, so let's bikeshed a bit here. I think on works better in Haskell because of the infix notation compare `on` length. While on wouldn't be horrible, I have the following suggestions:

• apply_on/map_on/get_map. I think those are more telling that we map a function over a specific field. However, it's not clear that the function has arity 2 (get_map sounds more like forall a b. String -> (a -> b) -> {_ : a} -> b). We can add 2 as a suffix but it's less nice
• zip_on: there is the precedent of zip_with, so zip is already used for applying a binary function with arguments coming from two different sources, which is nice. Maybe it should be theoretically zip_on_with but it's slightly uglier IMHO.

[jeremyschlatter]

I've been thinking about these names for an embarrassingly long amount of time and I'm starting to get semantic satiation 😅

Variants of zip and map both suggest to me that we'll be getting back a {_ : b}, not a b.

I considered at and variants of *_at but it again makes me kind of expect we'll get back a {_ : b} instead of a b.

apply doesn't have that connotation to me, so it feels better. I agree the 2-arity isn't obvious, but I'm inclined to just accept that. Besides zip the only idea I have to communicate it is appending a 2 at the end of the name, but I find that pretty ugly.

I kind of like apply_to.

That leaves my top choices as on / apply_on / apply_to.

The use case that motivated me to open this PR in the first place was sorting an array of records by name. Here's how that looks with these options:

 array.sort (record.on "name" string.compare)
 array.sort (record.apply_on "name" string.compare)
 array.sort (record.apply_to "name" string.compare)

I'm not committed to those, though, and I'm happy for you to unilaterally make a call. You have a lot more invested in nickel than I do.

[yannham]

Thanks for your input. I think I like apply_on, which combines the on and makes it clearer that we select one field (while to is a bit too generic IMHO and could relate to the records as well), but is more telling than just on. @jeremyschlatter would that be ok to do the renaming directly in this PR? After that we can merge.

[jeremyschlatter]

@yannham Done.

[yannham]

Great. Thanks again for contributing!