How do I combine CLI customizables with let ... in chains?

[vi]

Supposing I have something like this:

let a = ... in
let b = ... in 
...
... in
{
   output1: output1_,
   output2: output2_,
}

for use with nickel export ... --field output1.

How do I add a CLI-accessible knob that affects something at the top (e.g. a binding), so that it can be used as nickel export ... --field output1 -- a=1234?

---

Also how do I reuse let binding for the final output record, to avoid hacks like the_thing: the_thing_?

[yannham]

How do I add a CLI-accessible knob that affects something at the top (e.g. a binding), so that it can be used as nickel export ... --field output1 -- a=1234?

You need to have your bindings in a record, not in a let-binding. Basically let-binding are just aliases and aren't overridable. Record fields are. So something like:

# .. you can put stuff  before, even let-bindings - CLI customize mode will still work
{
  a | Number,
  b | Number,
  output = a + b,
}

$ nickel export foo.ncl --field output -- a=1 b=2
3

How it works is that the CLI will evaluate that to something equivalent to ((import "foo.ncl") & {a = 1, b = 2}).output where & is the merge operation that will take care of combining the values of a and b on both side.

Also how do I reuse let binding for the final output record, to avoid hacks like the_thing: the_thing_?

This is unfortunately not yet possible, but something we really want: #747.

[vi]

Is there a good way to splice function out that yields multiple fields into that big final record (with overridable fields).

Something like this:

let calc_both | Number -> {a,b,} = fun the_param => {
  a = the_param+1,
  b = the_param+2,
} in
{
  the_param | default | not_exported = 0,
} & calc_both the_param

, i.e. extract the merged value to process it, then merge back.

Workaround:

let calc_both | Number -> {a,b,} = fun the_param => {
  a = the_param+1,
  b = the_param+2,
} in
{
  the_param | default | not_exported = 0,
  
  ugly_tmp | not_exported = calc_both the_param,
  
  a | Number = ugly_tmp.a,
  b | Number = ugly_tmp.b,
}

[yannham]

I'm not entirely sure what you are trying to do. Usually the Nickel way is to use recursive records rather than function for configuration, because it's easier to inspect, to merge and to override. So, my natural inclination would be to just get rid of the function altogether and use only a record:

{
  the_param | default | not_exported = 0,
  
  a | Number = the_param+1,
  b | Number = the_param+2,
}

Or is there any reason you want a function? In many ways, a function fun param1 param2 => { field1 = ..., field2 = ..., etc.} is equivalent to a recursive record {param1, param2, field1 = ..., field2 = ...}.

[vi]

How do I factor out the_param+1 / the_param+2 calculation to a separate file?

a function ... is equivalent to a recursive record ...

How do I refactor big recursive records to span multiple files?

[yannham]

One possibility is to use merging. Say you want to separate the computations of a and b in different pieces.

You can split your records in multiple ones; the only gotcha is that you need to re-declare the fields that you will depend on (here, the_param), because Nickel has lexical scoping, and you can't refer to "some fields that might come in later during merging", you need to write it down explicitly. For example:

# part1.ncl
{
  the_param,
  a = the_param + 1,
}

# part2.ncl
{
  the_param,
  b = the_param + 2,
}

# params.ncl
# this files isn't required, but otherwise it's not clear where to put all the annotations on `the_param`:
# only in part1.ncl ? only in part2.ncl? in both? All those choices lead to the same result, but I personally
# find it better to separate the concerns and declare the interface in a third place.
{
  the_param
    | Number
    | not_exported
    | default
    = 0
}

You can then leverage the Nickel CLI: if you specify several files, they will be merged by default, so you can just run

$ nickel export params.ncl part1.ncl part2.ncl -- the_param=10

[vi]

OK, thanks for the advice.