Add functionInfo builtin#8961
Conversation
This function returns full information about the function, including its formal arguments, whether formals have an ellipse, and optionally the name of the @-pattern argument. Motivation: it's sometimes useful to know if the function uses @-pattern to know if it's safe to call it with callPackage-style, i.e. only passing its "formals" to it. i.e. useful in [254212](NixOS/nixpkgs#254212). A similar change has previously bee proposed as well NixOS#7317
|
#8908 also implements most of the reflection logic proposed here, as separate primops. |
roberth
left a comment
There was a problem hiding this comment.
A mostly equivalent change is proposed as part of
Differences to consider
- return an attrset or have multiple functions?
- 8908 is more consistent with
functionArgsand avoids committing the language to what I consider to be a bad name,formals - this could be considered to promote consistency by having a single format for the combined info
- 8908 is more consistent with
- use semantically meaningful names or syntactic names? The latter make interoperability with a possibly different syntax ugly. (think cue or python, or functions defined through the bindings)
- expose the difference between
a@{...}:anda:? the prior of which is strict and may perhaps warrant a custom error or warning in some cases
| // !!! should optimise booleans (allocate only once) | ||
| formals.alloc(i.name, i.pos).mkBool(i.def); | ||
| auto attrs = state.buildBindings(3); | ||
| if(args[0]->lambda.fun->arg) attrs.alloc("arg").mkString(state.symbols[args[0]->lambda.fun->arg]); |
There was a problem hiding this comment.
I believe we should not expose this information. It is not needed, and it will introduce unnecessary coupling that users will have to be aware of when renaming what is otherwise a completely internal name.
| for (auto & i : args[0]->lambda.fun->formals->formals) | ||
| // !!! should optimise booleans (allocate only once) | ||
| formals.alloc(i.name, i.pos).mkBool(i.def); |
There was a problem hiding this comment.
This appears to be common with the functionArgs primop and should be factored out.
| auto attrs = state.buildBindings(3); | ||
| if(args[0]->lambda.fun->arg) attrs.alloc("arg").mkString(state.symbols[args[0]->lambda.fun->arg]); | ||
| attrs.alloc("ellipsis").mkBool(args[0]->lambda.fun->formals->ellipsis); | ||
| attrs.alloc("formals").mkAttrs(formals); |
There was a problem hiding this comment.
I believe formals is an unfortunate name, and it has so far only been part of documentation, and not the language itself. This would be the last chance to fix that mistake.
args would match functionArgs. Will come back to this.
|
I've written #10350, to be triaged by the Nix team. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-11-27-nix-team-meeting-minutes-198/56691/1 |
This function returns full information about the function, including its formal arguments, whether formals have an ellipse, and optionally the name of the @-pattern argument.
Motivation
It's sometimes useful to know if the function uses @-pattern to know if it's safe to call it with callPackage-style, i.e. only passing its "formals".
Context
Useful in #254212.
A similar change has previously bee proposed as well #7317
It's also a less hacky solution to #194992
Priorities
Add 👍 to pull requests you find important.