Pre-RFC: pipe operator `|>`

Development RFCs
21

I would err on the side of caution on adding a plethora of Haskell infix operators. Without a type checker you’re effectively copying dogelang.

I’m all for |> though

3 Likes
23

bumping this thread in the interest of starting a conversation about pushing this forward more aggressively… One of the most challenging things about nix to new users is the absurd parenthesized expressions that are required for function application.

To get an idea of how much this brings in readability improvements, here’s an ast-grep rule that transforms nix code. It’s missing some corner cases when run against nixpkgs, but overall this handles the vast majority of usages of lib.pipe and (I’m guessing) the remainders could be fixed in an evening. So imo there’s a clear path forward.

# yaml-language-server: $schema=https://raw.githubusercontent.com/ast-grep/ast-grep/main/schemas/rule.json

id: 'Use new pipe operators'
severity: error
language: nix
rewriters:
- id: remove-parens
  rule:
    pattern: ($$$ELEM)
  fix: "$$$ELEM"

rule:
  pattern: '_MAYBEPIPE _F [ ___A ]'

constraints:
  MAYBEPIPE:
    regex: '(lib[.])?pipe'

transform:
  CONTENTS:
    rewrite:
      source: $$$A
      rewriters: [remove-parens]
      joinBy: "\n |> "


fix: "$F\n |> $CONTENTS"

Usage: throw this into the root of nixpkgs alongside nix-shell -p ast-grep,

$ cat sgconfig.yml
customLanguages:
  nix:
    expandoChar: _
    extensions:
      - nix
    libraryPath: "<REPLACE WITH pkgs.vimPlugins.nvim-treesitter.grammarPlugins.nix / parser / nix.so >"
ruleDirs:
  - ./rules/

We haven’t even started the wait game yet, though. I find that really frustrating.

3 Likes