Named ellipses

[deliciouslytyped]

I don't know what ... is called syntactically and searching ellipses didn't yield any relevant issues.

I think it would be nice if we could name the ... that is the extra parameters to a function, because it would mean we don't have to use builtins.removeAttrs to clean things up when one wants to just do {...}: { ..whatever.. } // extra. So this would clean up a lot of code?

Perhaps something like the following but maybe better syntax?: {a, b, c, ...@extra}@args: { ..whatever.. } // extra.

(How do other languages handle this?)

[infinisil]

I think the { a, ...@extra }: / { a, extra@... }: would be a nice and simple syntax extension that makes sense (everything in a function argument can bound with @ like this) and makes code nicer.

[deliciouslytyped]

So I guess if I wanted to try implementing this, I would need to: (mostly found via searching for "formals" and "ellipses")

• update the syntax around https://github.com/NixOS/nix/blob/399b6f3c46077e10a7047e8216fc1a67425a768a/src/libexpr/parser.y#L517 similar to https://github.com/NixOS/nix/blob/399b6f3c46077e10a7047e8216fc1a67425a768a/src/libexpr/parser.y#L320
• update https://github.com/NixOS/nix/blob/6924bdf2bf8f50f2e6ec5d490571594450aba13a/src/libexpr/nixexpr.hh#L217-L223 (or not, if adding to argNames is sufficient)
• TODO eval.cc, nixexpr.cc, primops.cc, value-to-xml.cc
• update docs
• update tests

[deliciouslytyped]

I've never done anything like this before, how can I try to implement it?:

The syntax changes look relatively simple. For evaluation I would need to add a formal argument, and also construct some sort of scope object for the formal argument? This would need to be constructed at eval time and the contents should show up in two places?:

• it should be an attrset with the arguments as attributes
• the arguments should continue to show up in the scope of the function as they have previously

[stale[bot]]

I marked this as stale due to inactivity. → More info

[stale[bot]]

I closed this issue due to inactivity. → More info

[Artturin]

Another issue asking for the same thing https://github.com/NixOS/nix/issues/2507

[roberth]

Generally, I would recommend to split your usage of attrsets into two roles:

• dictionaries, in which all names have the same role
• records, in which names have distinct roles, and the set of names is constant or at least bounded

When you stick to this dichotomy, the need to removeAttrs almost any attributes evaporates, with the added benefit that a dictionary entry can never collide with a record field. Furthermore the intent of the attributes becomes a bit more clear.

In the hercules-ci github organization, I have a whole bunch of projects, but very few uses of removeAttrs, and none would benefit from this.

For me the most significant use of removeAttrs in my code is in hercules-ci-effects, filtering out arguments that aren't valid for mkDerivation. That's emulating the Nixpkgs "generic mkDerivation" pattern, which is particularly worthy of regret. I'm resolving it in that project by migrating it to the module system instead. The module system enforces the same division, thoroughly by enforcing it through types.attrsOf and types.submodule, but with the notable exception of

• freeform types aka RFC42 settings, which blur the line, but not the attribute's intent
• module shorthand syntax, which has been a source of pain for module system development/maintenance (infinisil and I are the de facto maintainers of the module system)
• option trees, which has lead to bad errors when making mistakes in the option declarations, and similar trouble when consuming the options metadata in a part of the tree that retroactively receives a freeform type; option-merging a submodule.

That all said, it is actually the module system that may be a reason why I might not oppose this change. Its unifyModuleSyntax function is invoked 10745 times instantiating just nixosTests.simple and its behavior could possibly be simplified a lot, from traversing a non-trivial amount of AST to a single lambda invocation. However, this also requires the pattern match to be lazy!

(The number is in the correct ballpark, considering the 1385 root modules (module-list.nix), submodules, mkRenamedOptionModule, etc)

So, to avoid a false sense of improvement, my recommendation is to refactor the code instead, to get double the benefit, at the interface level, instead of a bit of DRY at the implementation level (so more than double? anyway, who's counting. It's strictly more). If you do wish to implement this, implement lazy matching as well, and only continue it if we can get a speedup in the module system.

It is just a recommendation; I won't oppose this, but it is a serious one.