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.

Sign up for GitHub

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
Closed

[RFC 0058] Named Ellipses #58

Changes from 9 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
5fda3ff
Create 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
c4f6cc9
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
1b74fac
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
c38f79a
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
23e5126
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
f1acf12
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
bde88ba
Update 0057-named-ellipses.md
deliciouslytyped Nov 14, 2019
776cb0f
accidentally interchanged some words
deliciouslytyped Nov 14, 2019
966bce4
added todo
deliciouslytyped Nov 15, 2019
3fe2733
Update rfcs/0057-named-ellipses.md
deliciouslytyped Mar 27, 2020
30108be
Update rfcs/0057-named-ellipses.md
deliciouslytyped Mar 27, 2020
8c4dd00
Update rfcs/0057-named-ellipses.md
deliciouslytyped Mar 27, 2020
9044d4e
Update 0057-named-ellipses.md
deliciouslytyped Mar 27, 2020
ff5795a
Add shepherd team to metadata
lheckemann May 28, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions rfcs/0057-named-ellipses.md
View file
Open in desktop
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 •
edited
Loading

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 •
edited
Loading

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