Live data from Hacker News

Typing Nix

tweag.io

51–60 of 128 posts

Re: Typing Nix

#51

Earlier quoted context omitted.

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

I see. But that means using a whitespace-sensitive syntax, which some people (including me ;) ) don't really like

Re: Typing Nix

#52
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 ?

(I can't reply to the previous message regarding no-semicolon syntax, so I have to do it here. I definitely do not want to propose whitespace-sensitive syntax — just newline-sensitive, like in Scala, Swift, modern ECMAscript, or just any modern programming language with C-like syntax. Semicolons are allowed, BTW — they are just optional and inferred from newlines).

Re: Typing Nix

#53

Earlier quoted context omitted.

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.

How about allowing for bloody danging commas?

Re: Typing Nix

#54
post #21

How does Nix compare with conda[0] ? I could not find any useful resource, in my team we were hesitating between the two, for packages management ; finally we went for conda because it (seems)is better documented and package description is easier to write for newbies. And also we are a Python shop, so other devs felt more comfortable with conda. Personally I prefer Nix, though, and I wanted to advocate for it but the…

I wrote this document: http://catern.com/posts/deps.html which briefly compares both Conda and Nix among other things. (warning: it's very pro-Nix :) )

You claim that conda "isn't very well supported by Unix as a whole" and "doesn't really work." Can you provide some evidence or examples to back up your claim?

Re: Typing Nix

#55
post #36
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 love the Nix language and I generally distrust aesthetic feelings about programming languages. Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example. The multiline interpolated strings in Nix are extremely much better than in SML or Haskell. The way records and arrays are written is great: SML and Haskell both suffer from the tedious problem of using separ…

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

Re: Typing Nix

#56
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.…

Honestly that's the only thing that keeps me from jumping to NixOS. I don't want to learn a weird language, I'll never use for anything else, just to maintain my OS.

Personally, I'm not against the idea in principle. There are some real DSL-haters out there, and I'm not one of them. For a different problem domain, a different language can be more efficient.

It's true that some DSLs are not only different, they're also badly-designed languages or gratuitously different. I guess this is an occupational hazard of DSLs, but it's not unavoidable. It's possible to make the leap to a DSL only when actually beneficial and then to design a DSL that doesn't suck.

Re: Typing Nix

#57
post #53

Earlier quoted context omitted.

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

How about allowing for bloody danging commas?

Is there any real disadvantage to comma-first, other than aesthetics (which is entirely a personal preference)?

Re: Typing Nix

#58
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.…

Really? I write almost nix every day at work and I have no problem with the syntax. I think it's pretty elegant and well-suited to its use case. There are a few minor tweaks I would make but nothing big at the syntactic level.

EDIT: probably the only gripe I would make is to have comma-separated lists instead of having to use parentheses to separate non-atomic expressions.

Re: Typing Nix

#59

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

AFAICT, there are 2 major differences between Nix and Guix. Language choice is the obvious one. The other is that Guix takes a hard-line stance on the GNU philosophy and therefore refuses to distribute pre-compiled binaries. I don't think CUDA will ever be an option on Guix.

Re: Typing Nix

#60

Earlier quoted context omitted.

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.

Go solves this problem by permitting

    foo := Foo{
        x: 10,
        y: 24,
    }
Post reply on HN