> Configurations in Nix are written in a full-fledged programming language, featuring all manner of primitive datatypes (numbers, strings, file paths, etc), anonymous records and first-class functions. This is a very big deal for writing configurations in the large. Functions allow code reuse and abstraction, two crucial ingredients without which writing out configurations by hand would become unwieldy. Off topic but…
Slightly related: Why does Github call Vimscript "VimL"?
Typing Nix
41–50 of 128 posts
Re: Typing Nix
#42E: In the paragraph titled "NIX TODAY".
Re: Typing Nix
#43I love Nix. NixOS is my primary development operating system. However, the Nix language itself is syntactically ugly , and this proposal makes it even uglier. Parentheses, sigils and special characters (esp. semicolons) are line noise — the less of it the better. Why they wouldn't take the most (syntactically) beautiful functional programming language out there — Standard ML? It would work perfectly for such a task.…
I could not agree with you more! I use nix daily, and every time I go to edit it a nix file a voice in the back of my head says, "you should really start that Haskell to Nix compiler you've been thinking about." [edit] ha! just notice the next comment talking about hnix. Great minds... :)
Re: Typing Nix
#44Earlier quoted context omitted.
You might be interested in dhall[0] and dhal-to-nix[1] which provides a really neat haskell-like language that compiles to nix. [0]: https://github.com/Gabriel439/Haskell-Dhall-Library [1]: https://github.com/Gabriel439/Haskell-Dhall-Library
If only Haskellers knew that "a blog post" and "type definitions in Hackage" are not documentation... Also, the comma-first syntax like { foo = "bar" , baz = "qux" } drives me nuts. In the name of all good things in the world, why?
oooh but this is one of those trivial things that I really liked in my brief days of using Haskell, and that has sometimes carried over to my C++, e.g. in initializer lists. I find it super useful because everything lines up nicely, and from the point of view of version control you don't have to edit the previous line to change '}' to ',' when adding a new line.
Re: Typing Nix
#45Earlier quoted context omitted.
You tried guix ? I still have a fondness for sexps, but ML would be nice too.
I need CUDA drivers for what I am working with, and I have found no way to install it in Guix. Otherwise, it looks interesting enough. (Sexps are usually not my first choice, I think it is a "lazy option" for people who do not want to write parsers / design their own syntax. Even then, they are better than current Nix expressions).
There are some real advantages to having one universal syntax: witness the explosion in XML and, later, JSON (both of which are generally inferior to S-expressions[1]). It'd be pretty great for one person to write one parser, and then everyone forever after to be able to use it. We'd be able to focus on semantics and not on syntax.
[1] Although it is nice that JSON supports first-class associative arrays.
Re: Typing Nix
#46Earlier quoted context omitted.
Community could be larger if all these petty things were resolved :) But I understand, forking is definitely not an option. So, if only gradual changes are allowed, I would have started with: - making semicolons optional - commas for implicit array literals (e.g. "a", "b", "c" in lieu of ["a" "b" "c"] - something to do with 'with' / 'in' syntax. In fact, I can live with anything, except non-optional semicolons. Is th…
The only place where I think we could make the semicolons optional is at the end of a let-binding or a record (like json does iirc), which would indeed be a small but blessed change. For the array litterals, I don't really see which improvements your syntax brings (except suppressing the space-separated list, which conflicts with the syntax for function application). Is it used somewhere else ?
https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...
For me, it looks infinitely better.
Re: Typing Nix
#47Earlier quoted context omitted.
Community could be larger if all these petty things were resolved :) But I understand, forking is definitely not an option. So, if only gradual changes are allowed, I would have started with: - making semicolons optional - commas for implicit array literals (e.g. "a", "b", "c" in lieu of ["a" "b" "c"] - something to do with 'with' / 'in' syntax. In fact, I can live with anything, except non-optional semicolons. Is th…
> In fact, I can live with anything, except non-optional semicolons. Is there a possibility to infer them? I'm genuinely curious... what makes that a dealbreaker?
Re: Typing Nix
#48- baked in fetchurl, fetchgit for easier bootstrapping
- a functional dsl for rendering filesystem hierarchies - instead of the find/sed/awk galore. 50% of the time when my nix recipe breaks it's not a nix syntax issue but something with bash. (reading nix is an exercise in learning new unix features)
- drop the channel feature entirely and make releases immutable tar files with hashes. I use nix as a build system on macos and right now a nix-channel update is a sure way to break all my builds which is the opposite of nix's promise
EDIT: formatting
Re: Typing Nix
#49I love Nix. NixOS is my primary development operating system. However, the Nix language itself is syntactically ugly , and this proposal makes it even uglier. Parentheses, sigils and special characters (esp. semicolons) are line noise — the less of it the better. Why they wouldn't take the most (syntactically) beautiful functional programming language out there — Standard ML? It would work perfectly for such a task.…
I don't have extensive ML or Haskell experience, coming from Ruby/Java background.
I think the Nix language works great as a configuration language, and I greatly prefer it to JSON, YAML, or Ruby, which are often used for similar purposes. The way arguments are passed in, merging of attribute sets, the library from Nixpkgs with various list and set operators and other utilities, and great multiline string support make it far superior to those other config languages in my opinion.
My biggest gripe is that the Emacs mode isn't very strong, so I'm often applying indentation manually.
I recently learned about Jsonnet[1] which has some similarity with Nix.
Re: Typing Nix
#50Sure it would be nice to have types for refactoring, but a more useful set of features would be: - baked in fetchurl, fetchgit for easier bootstrapping - a functional dsl for rendering filesystem hierarchies - instead of the find/sed/awk galore. 50% of the time when my nix recipe breaks it's not a nix syntax issue but something with bash. (reading nix is an exercise in learning new unix features) - drop the channel f…