[RFC 0058] Named Ellipses #58
Conversation
First draft
markdown fix
example
some cleaning
|
Note, I'm not really able to implement this by myself, so someone else will have to volunteer to implement it - or wait indefinite time for me to learn how. |
|
It has been proposed/pointed out to me over IRC that JavaScript uses A more reasoned counterpoint however, would be desiring consistency with using |
|
It may be relevant to this general discussion to explicitly point out that both |
rfcs/0057-named-ellipses.md
Outdated
|
|
||
| # 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] |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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. ;)
There was a problem hiding this comment.
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)
|
|
||
| `{...@extraargs}: extraargs` should yield as an attrset the extra arguments "in" `...`. | ||
|
|
||
| TODO: consider what other languages like Haskell do |
There was a problem hiding this comment.
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.
|
By the way, to avoid adding a new underspecified syntax construct in the language: is |
| TODO: The latter could be substantiated. | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design |
There was a problem hiding this comment.
It would be useful to have an example of how people are currently using removeAttrs somehwere in the RFC, for comparison.
There was a problem hiding this comment.
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.
The question is whether
|
|
> By the way, to avoid adding a new underspecified syntax construct in the language: is ***@***.***}: extra) {extra = 1;}` a runtime error?
The question is whether `extra = 1` should end up inside the `...` right?
- If yes then it should be fine though it might be a bit confusing if one happens to have a name collision?
Right now I'm leaning towards this option.
Hm, given the current behaviour of `(args@{...}: args) { args = 1; }` it does sound reasonable that for `(args@{extra@...}: [extra args.extra]) { extra = 1; }` we get `[{ extra = 1; } 1]`; but this should probably be mentioned.
|
|
Oh yeah, that's a nice and simple way to justify that. Naming |
edolstra
added
status: open for nominations
|
This RFC is now open for shepherd nominations. Any volunteers? I'm nominating myself :-) @7c6f434c Would you be willing to shepherd? |
|
I am close enough to being on the fence, so I accept the nomination. I would also like to nominate @jwiegley as the lead author of a popular alternative Nix parser. |
|
I personally would still like to see this happen, but do not have the capacity to push for it until further notice. |
|
Has somebody time else to come up with examples? |
|
@7c6f434c could you organize a meeting for this one? |
|
Meeting, meeting… let's start by finding out if there is enough substance… @deliciouslytyped are you interested in writing up more detailed motivation section for this RFC in any close future? @jtojnar are you interested in maybe taking over / partially taking over this? |
|
@7c6f434c Unfortunately, I do not have the bandwidth at the moment. |
|
@deliciouslytyped apparently my previous mention was just before you returned online. |
|
Sorry, still distracted. |
|
My opinion on meeting: it would be a cargo-cult as whatever is discussed will not realistically be implemented in predictable time. My opinion on the current state: I am turning towards the idea to close with the decision like «defer». There is some level of positive interest in the community, and there is a question if enough consideration has been given to the costs and to the design trade-offs. Accepting this requires either more work on surveying the current Nixpkgs situation, potential mode of use, and consistency with other similar constructions in Nix and possibly in other languages; or maybe an implementation plan, which should both incentivise the justification work and allow to confirm the limited impact from varoius points of view. Once someone has energy to either improve the justification part or implement it, the discussion can be continued. [This is not yet a call for FCP, and probably not yet exactly the disposition I want to propose, just the likely direction] |
|
Shall we close this until we have some developments here? |
|
Almost a month later, I formally motion for FCP with disposition to close until interest in further work is present. We have seen some interest in this feature, but to commit to a design as an RFC decision either more surveying/documentation work (and discussion of specific trade-offs based on more data) or some prototyping would be needed. Continuation of discussion might be a reopening or a new RFC. |
|
Sure, I agree, let's FCP it. It's a convenient feature, but not something we have seen massive reason to push for yet. |
|
Thanks. Final Comment Period starts on this RFC with a disposition to close as «deferred». The proposal got positive feedback, but more work is needed for final commitment to accept details of the design. Thanks to everyone who contributed to the discussion, hopefully the record will be useful at some future point when we revisit this topic. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfc-0058-fcp-named-ellipses-with-disposition-to-defer/9603/1 |
|
Thanks, I've closed with label "status: deferred". |
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 ofremoveAttrsthat really just want to refer to the contents of ellipses.Rendered
Edit:
Proposed discussion point:
Should scope of this be expanded to binding any function argument to new names - for consistency, even though that might be considered redundant? E.g.:
a@{b@c, d@...}: nullMaybe it's preferable to get this simple RFC through first though.