> If you can make a better surface syntax

... http://gnu.org/s/guix

Lisp is pretty good at lists.

The only important language is the derivation language sent to the daemon. Nix spends so much time building up inputs... for shell scripts. I always felt like they would have been so much more successful if they chose some other, more popular language to generate derivation.

I dig Guix, but Lisp is also one of the most commonly reviled syntaxes, so it's hard to say it's clearly better, or that Nix would enjoy more adoption with S-expressions.

Reviled by people who have never used it.

Most commonly and with lots ans lots of prejudice.

Is it possible to write a guix package that includes code which redefines the package object?

Yes!

http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/...

You'll see here that the package emacs-minimal actually inherits from the emacs package definition, and then all fields afterwards are essentially overwrites of whatever was in the emacs package.

Unfortunately, I just noticed that the manual alludes to this, but actually never explicitly documents it in the "Defining Packages" section :/

> Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example.

Purescript's extensible row types handle this process elegantly and if Nix takes a cue from that, it will work great.

So, JavaScript? The records literals are JSON, which is the most popular syntax for this at the moment anyways.

No, Nix syntax is much nicer than Javascript. Consider, for example, the similarity between a let expression and an attribute set (NOT JSON by the way):

  let
    foo = 42;
    bar = "a string";
  in {
    baz = "deja";
    quux = "vu";
  }

Javascript:

  const foo = 42;
  const bar = "a string";
  return {
    baz: "similar",
    quux: "but different"
  };

You find this kind of thing all over the place. Nix is a much smaller and simpler language syntactically, and more pleasant to write.

Also, recursive definitions using "rec" which become nasty in JavaScript.

I tend to write JavaScript that looks a bit like Nix... but in general, the imperative constructs aren't suitable to the lazy evaluation strategy of Nix.