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

Conversation

deliciouslytyped
Copy link

@deliciouslytyped deliciouslytyped commented Nov 14, 2019

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.

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@...}: null
Maybe it's preferable to get this simple RFC through first though.

@deliciouslytyped
Copy link
Author

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.

@deliciouslytyped
Copy link
Author

It has been proposed/pointed out to me over IRC that JavaScript uses ...somename.
I don't particularly have a preference - I didn't know there is a language that does this, but it initially felt somewhat aesthetically ugly, having no separator between whatever ... is, and the name. I consider my preference arbitrary though.

A more reasoned counterpoint however, would be desiring consistency with using @ like in a@{whatever}:?

@deliciouslytyped
Copy link
Author

deliciouslytyped commented Nov 15, 2019

It may be relevant to this general discussion to explicitly point out that both a@{}: null and {}@a: null are valid. Not everyone knows this.


# 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)


`{...@extraargs}: extraargs` should yield as an attrset the extra arguments "in" `...`.

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.

@7c6f434c
Copy link
Member

By the way, to avoid adding a new underspecified syntax construct in the language: is ({extra@...}: extra) {extra = 1;} a runtime error?

TODO: The latter could be substantiated.

# 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.

@deliciouslytyped
Copy link
Author

deliciouslytyped commented Nov 17, 2019

By the way, to avoid adding a new underspecified syntax construct in the language: is ({extra@...}: 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. Not because it seems easier, but because I feel it makes more sense.
  • if no, you shouldn't be allowed to do that because - how do you say this... the name is being created by the interpreter - right?
    In which case I think we should fail at non-runtime if possible...

@7c6f434c
Copy link
Member

7c6f434c commented Nov 17, 2019 via email

@deliciouslytyped
Copy link
Author

deliciouslytyped commented Nov 17, 2019

Oh yeah, that's a nice and simple way to justify that.
(args@{...}: args) { whatever } == (args@{extra@...}: args) { whatever }
Edit: (question is are there any weird edge cases)

Naming ... should preserve the the semantics in the case of success.

@edolstra
Copy link
Member

This RFC is now open for shepherd nominations. Any volunteers? I'm nominating myself :-) @7c6f434c Would you be willing to shepherd?

@7c6f434c
Copy link
Member

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.

@deliciouslytyped
Copy link
Author

I personally would still like to see this happen, but do not have the capacity to push for it until further notice.

@Mic92
Copy link
Member

Mic92 commented Aug 13, 2020

Has somebody time else to come up with examples?

@Mic92
Copy link
Member

Mic92 commented Aug 27, 2020

@7c6f434c could you organize a meeting for this one?

@7c6f434c
Copy link
Member

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?

@jtojnar
Copy link
Member

jtojnar commented Aug 27, 2020

@7c6f434c Unfortunately, I do not have the bandwidth at the moment.

@7c6f434c
Copy link
Member

@deliciouslytyped apparently my previous mention was just before you returned online.

@deliciouslytyped
Copy link
Author

Sorry, still distracted.

@7c6f434c
Copy link
Member

7c6f434c commented Sep 3, 2020

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]

@lheckemann
Copy link
Member

Shall we close this until we have some developments here?

@7c6f434c
Copy link
Member

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.

@edolstra @jD91mZM2

@edolstra
Copy link
Member

@7c6f434c I agree, let's FCP this for now. (Maybe @jD91mZM2 wants to reply as well.)

@jD91mZM2
Copy link
Member

jD91mZM2 commented Oct 22, 2020

Sure, I agree, let's FCP it. It's a convenient feature, but not something we have seen massive reason to push for yet.

@7c6f434c
Copy link
Member

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.

@nixos-discourse
Copy link

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

@edolstra
Copy link
Member

edolstra commented Nov 5, 2020

Thanks, I've closed with label "status: deferred".

@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/is-it-possible-for-us-to-remove-builtins-functionargs/51960/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.