Live data from Hacker News

Typing Nix

tweag.io

41–50 of 128 posts

Re: Typing Nix

#41
post #33

> 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"?

It's not just Github, the Vim filetype is "viml". It's a standard name for the language. Most likely meaning Vim Language.

Re: Typing Nix

#42
Just a heads up to the author that the link to Nixpkgs is not working, shows up as [Nixpkgs][nixpkgs]

E: In the paragraph titled "NIX TODAY".

Re: Typing Nix

#43
post #6

I 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... :)

Wow, I'm doing the opposite where I'm staring at all these other DSLs and configuration files and have to hold myself back from writing a bunch of nix to autogenerate them from.

Re: Typing Nix

#44
post #24

Earlier 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?

> comma-first syntax

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

#45

Earlier 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).

> 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.

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

#46
post #40

Earlier 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 ?

Here is the example where I just removed every semicolon.

https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...

For me, it looks infinitely better.

Re: Typing Nix

#47

Earlier 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?

Just look:

https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...

Re: Typing Nix

#48
Sure 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 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

#49
post #6

I 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 may be in the minority, but I like the Nix language.

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.

[1] http://jsonnet.org/

Re: Typing Nix

#50
post #48

Sure 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…

For your last point, you don't have to use the channels (which will anyway be deprecated at some point iirc), and you can pin the nixpkgs version in your nix files (like it is done in https://garbas.si/2015/reproducible-development-environments...)
Post reply on HN