Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0058] Named Ellipses #58

Closed
wants to merge 14 commits into from
36 changes: 36 additions & 0 deletions rfcs/0057-named-ellipses.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
feature: Named Ellipses OR function argument consistency
start-date: 2019-11-14
author: deliciouslytyped
co-authors: none
shepherd-team: (names, to be nominated and accepted by RFC steering committee)
shepherd-leader: (name to be appointed by RFC steering committee)
related-issues:
Named Ellipses - https://github.com/NixOS/nix/issues/2998
---

# Summary
[summary]: #summary

It should be possible to bind a name to ellipses in a function definition like `{ a, ...@extra }: null`, and `{ a, extra@... }: null`. This makes intuitive sense, and could remove the need for a lot of uses of `removeAttrs` that really just want to refer to the contents of ellipses.

TODO: The latter could be substantiated.
deliciouslytyped marked this conversation as resolved.
Show resolved Hide resolved

# Detailed design
[design]: #detailed-design
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be useful to have an example of how people are currently using removeAttrs somehwere in the RFC, for comparison.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's what I meant. I'll add something when I have some spare brain for it, unless someone else wants to give it a shot.


`{...@extraargs}: extraargs` should yield as an attrset the extra arguments "in" `...`.
deliciouslytyped marked this conversation as resolved.
Show resolved Hide resolved

TODO: consider what other languages like Haskell do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that you want to consider pattern matching libraries, too, not just function arguments.

Some languages use notations that wouldn't fit well with the current use of ... in Nix: def f(a,b,*args): in Python, (lambda (a b &rest args) …) in Common Lisp.


# Drawbacks
[drawbacks]: #drawbacks
None? This implements syntax that would not have worked before and so in theory shouldn't cause breakage in the Nix ecosystem. [Citation Needed]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that Nix has a complicated enough syntax that increasing syntax complexity should be recognised as a drawback per se to be considered in comparison to the benefit. Every syntactical construct is a cost for third-party Nix-processing tooling, for example.

(I am not saying this drawback overweights the benefit here)

Copy link
Author

@deliciouslytyped deliciouslytyped Nov 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reluctantly agree and will add something later.

The lack of "user space" extensibility of Nix's syntax combined with that argument seems like a surefire way to tarpit any discussions about syntax "improvements", but I'm less experienced and still like more features. ;)

Copy link
Member

@7c6f434c 7c6f434c Nov 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I think of it, the functionality (although not the syntax) could indeed be added as a library function (as a higher-order function).

(Or maybe I am wrong, there are a lot of details to check, I guess)

deliciouslytyped marked this conversation as resolved.
Show resolved Hide resolved

# Alternatives
[alternatives]: #alternatives
Not doing this would not have any major impact besides not making nix and nixpkgs nicer to use.

# Unresolved questions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's drop this section as no strong motivation for argument renaming has been provided.

[unresolved]: #unresolved-questions
Should scope of this be expanded to binding any function argument to new names - for consistency, even though that might be considered redundant?
deliciouslytyped marked this conversation as resolved.
Show resolved Hide resolved