Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typing Nix

tweag.io

Post reply on HN
Print view View original

31–40 of 128 posts

Re: Typing Nix

#31

Post by make3 »

mguijarr wrote: post #12

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 use conda every day in my professional deep learning practice and it's a HUGE time saver. I can't press enough how I'm sure it's already saved me weeks if not months of package butfucking.

Re: Typing Nix

#32

Post by atemerev »

regnat wrote: post #24
dtwhitney wrote: post #19

Earlier quoted context omitted.

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

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?

Re: Typing Nix

#33

Post by dmix »

> 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 this brings up a good point I've been curious about for a long time. Does anyone know why VimL is such a terrible language?

It's fascinating to think what potential it could have with a modern language natively supported like this. The use of Python/Lua etc seem like complicated hacks on top of it, not to mention the API with tons of globals.

Re: Typing Nix

#34

Post by atemerev »

zimbatm wrote: post #23
atemerev wrote: 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.…

If I only look at the language properties then Nix makes sense to me. The fact that Nix is lazily evaluated allows for easy composability. This is used a lot in nixpkgs to allow overrides and build up packaging layers. And because the language is interpreted, only the files that are being used need to be evaluated. It wouldn't be very practical to hold all of nixpkgs in memory. It also allow to do things like dynamic…

I am only talking about the syntax. Semantically, Nix absolutely rocks.

Re: Typing Nix

#35

Post by majewsky »

dmix wrote: 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"?

Re: Typing Nix

#36

Post by mbrock »

atemerev wrote: 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 separators between items instead of after each one; in Nix each item can always be moved without messing with separators.

I think Nix is an engineering marvel up to and including the language design. If you can make a better surface syntax and demonstrate it by translating some significant part of Nixpkgs, I'd be very interested, but I think in general the language is the way it is because that's what made most sense for the system's designers.

Re: Typing Nix

#37

Post by regnat »

ykler wrote: post #29
regnat wrote: post #20

Earlier quoted context omitted.

Unfortunately no, except maybe for some very minor tweaks that have a chance to be included in vanilla nix, but otherwise this would most probably either mean the death of this project or a split in the (already small) community, which I both don't want to see

Can't it just accept two different syntaxes (if really necessary for disambiguation, perhaps requiring people to put some magic string at the beginning of the file to request the new syntax)?

My tool could, but (for now, at least) it is a separate project from the main Nix interpreter, and this one is notably slow to evolve

Re: Typing Nix

#38

Post by porker »

regnat wrote: post #20
atemerev wrote: post #15

Earlier quoted context omitted.

Is there any option to break source-level compatibility? (Automatic translation to old syntax will still be possible and seamless, of course). If yes, I can draft a proposal.

Unfortunately no, except maybe for some very minor tweaks that have a chance to be included in vanilla nix, but otherwise this would most probably either mean the death of this project or a split in the (already small) community, which I both don't want to see

Is that a definite no, and there's no chance of compiling whatever $newLanguage is written to the current nix code prior to execution?

If that was possible, and a few $000 was raised (looking at the comments here, I think people would chip in) then a new version of the Nixlang with the same semantics and full backwards compatibility but a cleaner syntax, would be a great project to fundraise for.

Re: Typing Nix

#39

Post by tonyarkles »

atemerev wrote: post #25
regnat wrote: post #20

Earlier quoted context omitted.

Unfortunately no, except maybe for some very minor tweaks that have a chance to be included in vanilla nix, but otherwise this would most probably either mean the death of this project or a split in the (already small) community, which I both don't want to see

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

#40

Post by regnat »

atemerev wrote: post #25
regnat wrote: post #20

Earlier quoted context omitted.

Unfortunately no, except maybe for some very minor tweaks that have a chance to be included in vanilla nix, but otherwise this would most probably either mean the death of this project or a split in the (already small) community, which I both don't want to see

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 ?

Post reply on HN