rfcs
rfcs copied to clipboard
NixOS
[RFC 0148] Pipe operator
Discussion notice: please try to attach all discussions to a thread by using the code review feature. If your comment doesn't refer a specific line to attach to, use the header line instead.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/pre-rfc-pipe-operator/28387/3
I am very well aware of the language's complexity. I am also aware of the fact that some of its users are very technical and into functional programming languages, and for many others this is a first contact with these concepts.
This is why I suggest picking only one of these operators as a compromise. I don't have any overly strong preferences here, but I make a point against function composition instead of argument piping, because the former leads to the so-called "point-free" programming style which tends to be more confusing for new users. I picked |> because of its similarity to the existing lib.pipe and the |> operator in Nickel, but if you are concerned about reversing control flow, then <| is a viable alternative too.
I strongly oppose calling this proposal "accidental" complexity. I spent a lot of time thinking about the options and trying to balance expressiveness and complexity, finding a compromise that makes solving real Nix problems easier. The Nix language is full of weird quirks users eventually have to face: we even have a wiki article collecting such instances, and it is far from exhaustive. Feel free to call these accidental complexity. But nothing about this proposal is accidental.
To be clear, I don't use accidental to describe this RFC. I only used it in accidental complexity, which I've used as a synonym for extrinsic complexity. I can see that you've put a lot of thought into it, and I respect that, but that does not necessarily make the change a net positive.
expressiveness
A language with more syntax may be easier to write, but is not more expressive unless the syntax comes with semantics that were not already covered by existing features and combinations of them.
makes solving real Nix problems easier.
What is a real Nix problem? At least the lack of a syntax won't end up on the quirks page.
Are the quirks a problem? Probably. I'd be happy to see a proposal that simplifies the language or makes the syntax easier to learn, but those are hard problems with a lot of inertia, and up-front costs that aren't "repaid" for years into the future. Pragmatically, I think the real Nix problems aren't in the syntax. We might reach a stage where we could simplify the syntax and possibly redo it to make it more accessible to people who use more commonplace languages. That's not in the coming five years though, unless we radically expand the Nix team, which is rather resource constrained today.
Nix is already considered to be overly complex by many.
And more people consider Nix awkward to read and write rather than being complex. Mostly because the standard library is poor and not discoverable.
|> would definitely make Nix less awkward to use.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/pre-rfc-pipe-operator/28387/10
A language with more syntax may be easier to write, but is not more expressive unless the syntax comes with semantics that were not already covered by existing features and combinations of them.
I disagree with your interpretation of the word "expressiveness". Because you can (almost) always already solve all existing problems with existing syntax in (almost) any programming language. That's the point of being Turing complete. Therefore the question then becomes, how well can a problem be expressed in the language. And I think this holds true even for changes that are purely syntactical, like this one.
When adding new syntax to the language, one goal may indeed be to make it easier to write. Another one, and IMO much more important, is does it make the language easier to read. Depending on the feature and the language those may coincide, or one may have the other as a side benefit, or they may contradict each other. I recently learned Haskell, so I am very well aware of the trap of having a lot of powerful operators that allow it to write programs concisely and without parentheses, but which comes at the cost of readability.
What is a real Nix problem?
Problems that one might face when writing Nix code, either for some flake/shell/system configuration or when contributing to Nixpkgs. What I mean with this, is that I don't want to solve problems that for example mostly occur when trying to solve AdventOfCode in Nix.
I think going through with this RFC would take gigantic effort
Honestly, the most effort in this RFC is convincing people, and maybe also the coordination across many projects. But from the technical side of things, this is actually pretty easy to implement.
and the positive results (if any) will be seen only after a few years.
This only applies to Nixpkgs, see https://github.com/NixOS/rfcs/pull/148#discussion_r1209471419
And I'm thinking those positive results aren't worth it, because they won't make Nixlang significantly easier to read for beginners, and they don't solve any technical issues with Nixpkgs or Nix.
They also won't make it significantly harder for beginners to read Nix code IMO, while bringing quality of life improvements to everyday Nix development.
I don't understand why only "technical" problems should be worth solving.
@AndersonTorres because I don't know every programming language and just didn't come across OCaml during my research. Furthermore, the related work section is intended to roughly cover the design space, not to be an exhaustive list of every programming language.
Updated the text according to some of the initial feedback. The more I think of it, the more I'm leaning towards also having <| in the language. I'll try to conduct a larger Nixpkgs survey soon to get some more data on that question. (Function concatenation operators are still out IMO)
I was thinking on it, precisely, two pipe operators! It makes the language more orthogonal: if we have arg |> function, it looks reasonable to have function <| arg as its reverse operator.
The problems are:
-
if we are to elevate
pipetobuiltinsandpipe == |>, where is the builtin for reverse pipe? Theapplypreviously suggested looks good to me; -
how the pipes should interact when in a same statement (
a |> b <| c,a <| b |> c)? I suggest to APLize: same precedence, right-to-left associativity (a |> (b <| c),a <| (b |> c)) -
a problem for the parser team: how should the errors be reported?
I nominate @maralorn, who has a lot of experience with functional programming languages and programming language design.
@roberth, what about you, would you like to be a shepherd? I'd rather like to have critical voices on board from the beginning …
I nominate @maralorn, who has a lot of experience with functional programming languages and programming language design.
I am pretty certain there are a lot of people with more experience on this in the wider community. That doesn’t prevent me from having opinions on this particular bikeshed, though. :rofl:
My availability depends on the timeframe here. I will be very busy in the next few weeks, after that I’d be on board.
I've procrastinated writing this RFC for at least half a year, so waiting two more months won't be the end of the world
I did a survey of some randomly sampled Nixpkgs files for this RFC here: https://github.com/NixOS/nixpkgs/pull/238579. I'll update the RFC with the results later on.
@edolstra I'd like to, but don't have much experience yet with the internals of Nix, especially the language evaluation itself, so uncertain if I'm qualified.
@iFreilicht having a diversity of fields of expertise in the shepherd team is a good thing, so your participation would be welcomed and valuable for moving the RFC forward :)
My availability depends on the timeframe here. I will be very busy in the next few weeks, after that I’d be on board.
@maralorn is your availability such that you can accept the nomination at this point?
I see two shepherds @roberth and @iFreilicht. I believe we still need 1 more.
@piegamesde did I miss someone? I reviewed the comments again and can't find the second shepherd that you mentioned.
having a diversity of fields of expertise in the shepherd team is a good thing
No expertise in language design is a good thing for this RFC specifically? Asking for a friend.
@AndersonTorres It's very hard to find a charitable interpretation of your words. You might want to reconsider your reply.
I'm talking in a literal way: knowing about programming language design is a pre-requisite?
I do not think that domain knowledge is a requirement for becoming a shepherd, even though it generally is a good idea to have some within the shepherd team (which we do).