Syntax questions

[axelkar]

Why was let..in chosen to not have multiple values?

The following is valid in Nix, but not Nickel. Why?

let
  a = 1;
  b = 2;
in a + b

Why is there no special syntax for type (definitions) and modules?

The import function is like replacing the function call with the target file. I said that because module-level syntax like pub struct ... or export interface ... isn't possible (#805). Maybe I am too used to Rust and TypeScript but I feel like strong typing with normal structs/interfaces, traits, tagged unions (solution to #781), etc. would be amazing in a configuration language such as Nickel but you are free to correct me.
Contracts are regular functions in regular let..in expressions, which I get confused by but I guess if they are exported or imported it's done by regular records and regular let..in expressions. (#911, #422 ?) I also get confused with a | Str | default "default" and a | Str | default = "default"; how does it even work?

[matthew-healy]

Hey @axelkar - thanks for the questions!

For the first one, while you're correct about the current state of things, a final decision on this hasn't yet been made. Allowing for multiple bindings in a single let ... in expression is something several members of the team would like, but it's not something we've prioritised implementing yet. Ultimately, it's just syntactic sugar, and we'd rather focus our efforts on core language functionality before we address "surface-level" features like this. (Though PRs are, of course, welcome.)

I'm not sure I'm the best person to answer the second question, but I can try to explain my current understanding and others can chime in to correct me if I go wrong. Basically, Nickel takes the view that most configuration is best expressed as a "record" structure, and as such the type system is laser-focused on providing a good experience for working with records. This is less restrictive than you might first think, as - at least in our experiences - the majority of types that end up being useful in configuration are some combination of "primitive" types, record types and function types.

While there is no module system per-se, you can emulate modules by writing a file which evaluates to a record containing the contracts, values & functions you want to expose. Equally you can emulate something like a Rust struct with static record types (though admittedly we're lacking type aliasing & nominal typing, both of which would make that a much more compelling proposition).

That being said, if you feel there's functionality that is missing & can provide good use cases for it, please open an issue for it.

Finally, as for a | Str | default "default" - that's not valid syntax. a | Str | default = "default" is valid (& expresses that a should satisfy the Str contract, has the default merge priority, and its value is "default"). It's possible you're confusing default with doc in the first case - a | Str | doc "This is a" attaches the documentation string "This is a" to a, which can then be viewed when using the LSP.

[axelkar]

Thank you for your answer! I must have misread the last portion from somewhere in the docs.

[yannham]

For reference:

• here is the original discussion on let-blocks: Block syntax for let-binding #494
• we looked into algebraic data types (ADT, Rust's enums). Basically contracts for those would be pretty hard in the general case (surprisingly), and we've even wrote a paper about that. The corresponding blog post might be a good introduction.

At this point, ADTs are now [EDIT: not] out of the question. Our original stance was that we don't want to chose an encoding for the user (how do you represent a Rust enum in JSON? Well, even e.g. wasm-bindgen in Rust doesn't want to answer that for you, because there are different equally valid ways). So, we wanted to provide users with different constructs (namely unions and a form of flow-sensitive typing) to get the same thing in practice, but letting the user chose the encoding. This turned out to be an unreasonable trade-off (explained in the paper).

That being said, ADTs could still be useful only internally, for example to pass data to and from library functions. If there aren't going to be exported, then we might just not care about how to represent them in JSON. That is another possible road: add ADTs, but refuse to serialize them. That wouldn't land before 1.0 though, because while it's useful, we don't think at this point this is required to build useful stuff with Nickel.

[N4tus]

As far as I understand default does not take a value. It only places the field to the last priority in the merge order. Since applying contracts is commutative a | Str | default = "default" and a | default | Str = "default" should be the same (If I am wrong please correct me).