I don’t know if it’s the best way, but this works:

I don’t know if it’s the best way, but this works:

lib.listToAttrs (lib.imap0 (x: y: lib.nameValuePair (toString x) y) x)

I don’t know if it’s the best way, but this works:

list: lib.listToAttrs (lib.imap0 (x: y: lib.nameValuePair (toString x) list) x)

I don’t know if it’s the best way, but this works:

list: lib.listToAttrs (lib.imap0 (x: y: lib.nameValuePair (toString x) y) list)

In reply to @reckenrode:matrix.org
Wish Nix supported function composition ….

In reply to @calops:tocards.net
what do you mean by function composition ?

In F#, I could write that as something like:

lib.map0 (toString >> lib.nameValuePair) >> lib.listToAttrs

>> is equivalent to . in Haskell.

Actually, << is equivalent. F# supports both left and right composition. I prefer >> because it reads like constructing a pipeline.

In reply to @winter:catgirl.cloud
be the change you wanna see in the world :3

In reply to @reckenrode:matrix.org
They haven’t even accepted the piping operator yet, and composition has potentially way worse impacts on readability.

Maybe helpful additional information: |> (or "pipe last") is a standardML-ism, as far as i can tell.
WRT composition: |> is function composition, but the functions are curried.

In StandardML (as in Nix and F#), functions are unary so you write a lot of let add = x: y: x + y. This means you can partially apply add trivially with let add2 = add 2. |> is simply an infix operator that translates add2 4 to 4 |> add2. For such a trivial example, it's really neither required nor helpful.

This operator really shines when you have something that does repeated list/vector/array processing pipelines: let eleven = [1, 2, 3,4 ] |> List.filter i: i %2 == 0 |> List.map i: i*i | List.fold 0 i: i + i; (or something). IMO it really well encompasses the idea of "we have a bunch of steps and we're doing them in succession to find a final result".

but there are a lot of useless uses of it in the wild too. To each their own tho.