Hacker News Reader

Comment by dbcurtis | Hacker News Reader

After a quick look at Nix syntax, it seems to me that it is almost JSON but different enough to required all new parsers. Maybe I'm wrong about that. But... why not just use JSON?

View on HN

Nix is actually a purely function programming language - you can embed function calls in it. This is used to great effect in various parts of nixpkgs - the entire thing is actually a program which returns the Nix package tree (but is not fully evaluated unless you explicitly ask for it).

OK, I replace my naive question above with a different naive question: "Why not just use Haskell?"

Haskell is honestly a larger language, and is a pain in the butt to write. If you're just writing configuration or a very simple package, Nix is basically "JSON with colons, multiline strings, and function calls". Haskell doesn't have a reasonable built-in syntax for dictionaries/maps/whatever you want to call them, which is 95% of Nix.

Well, you would use records, but records are a weak point of the Haskell language. I've discussed "why not Haskell" with some Nix people and they specifically mentioned the lack of row polymorphism.

You couldn't reasonably create a record for the NixOS configuration - the amount of options (fields) is massive. The all-packages.nix file is an untyped dictionary mapping strings to derivations as well.

Purescript?

Can I just point out that pretty much all of these options, including guix, are things that were invented well _after_ nix was established as its own thing?

(aside from Haskell and Scheme themselves, of course)

I don't think you need to worry, I'm sure that who's familiar with PureScript also knows it's more recent than Nix.

Those PureScript records tho...

Purescript cannot type a record merge or join. Haskell with type families can, but the syntax would not be very pretty.

A third naïve question: why not just use a functional subset of Scheme? It's got a well-defined syntax for key/value mappings, which is fast enough, funcalls, and you can use lazy evaluation if you use a pure subset of the language.

And in any rnrs complient Scheme, it's fairly trivial to make a strict functional dialect. And in Guile or Racket, it's even easier.

Unfortunately, Guix doesn't do this. Which meant Guix can't guarantee referential transparency. Although if the packager is an ANY WAY competant, it will be maintained.

A purely functional subset of Scheme, honestly, is different enough from most lisps that it's a new language on its own. If you're learning a new language, a new syntax isn't very hard. And there's not a terrible amount of people who think S-expressions are an inherently good syntax.

>A purely functional subset of Scheme, honestly, is different enough from most lisps that it's a new language on its own.

No, it's not. It's a cut-down Scheme: Most of your scheme knowledge would apply directly, or indirectly.

Besides, even if it was a different language, it's a pre-existing one: DSSSL is pretty much this.

>If you're learning a new language, a new syntax isn't very hard.

Yes, but for me, the choice is learning a new language that has no other applications, save package managment, and using a subset of a language I already know.

>And there's not a terrible amount of people who think S-expressions are an inherently good syntax

I said from my perspective. I'm a schemer, so I'm already on board with sexprs.

> No, it's not. It's a cut-down Scheme: Most of your scheme knowledge would apply directly, or indirectly.

Only if you regularly write code using purely functional scheme in the first place. The difficulty of writing in a new language is very rarely figuring out what function calls to make, at least for me - it's about thinking in terms of the language.

Do you know what % of scheme is fairly functional? Most of it. There are ~19 functions in r5rs that mutate state, if you count IO related functions. I have used maybe half of them, and mostly the IO ones. The rest were for mutating variables, lists, vectors, and strings. Many of those are rarely used. I mean, really, when was the last time you used set-car! or set-string!?

Scheme has little to offer out-of-the-box as a basis for Nix. It has no convenient syntax or suitable implementation for extensible records, which is the core data type of Nix.

  '((extensible-records . being-key-value-maps?))

Alists are fast enough for this, and they ARE k/v maps. And support for them is in rnrs.

They kind of suck syntax-wise though. There's no visual difference between them and any other list.

  '(this is a list)
  '((this . is) (an . alist))

Looks pretty distinct to me.

    '((this . is) (a . list) (of . cons))
    '((this . is) (an . alist))

Hey look, my list of cons looks incredibly like an alist... funny that.

So an alist looks like an alist. I'm shocked.

and alist is a list of pairs. That's what it is. Semantically, there isn't really another reason to use the format.

JSON isn't a programming language.

True enough. Maybe I've not seen enough of what is in a Nix packaging script.

Nix is isomorphic to JSON + lambda + let-rec, made lazy.

You can use `builtins.toJSON` and `builtins.fromJSON` to inter-operate with JSON.

They don't handle functions or infinite datastructures though.

Reply on news.ycombinator.com