You can install Nix in a totally unprivileged fashion, without having to use hacks such as PRoot, you just need to configure it to use a directory you have write access to instead of /nix. But doing so breaks the ability to use the official binary caches (because relocating the store requires recompiling packages), and this isn't particular to nix (I remember that portage at least does this too, and probably some others).
The interesting part is that with an installed deamon, the admin can allow users to install packages in their own profile, while still benefiting from sharing of dependencies and other niceties.
About the multiple versions, the problem with "classical" package managers is that you have to do some manual renaming to ensure that both versions won't be installed in the same place in the file-system, which is tedious and doesn't scale well. Furthermore you may encounter some problems because both will be visible at the same time if the packager isn't careful enough. For example, if a software X has a dependency of libfoo2.1 and you happen to have libfoo3.1 also installed, the installation script for X may use libfoo3.1 instead of libfoo2.1, in which case you risk to encounter bugs because X hasn't been tested against libfoo3.1.
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.
Yes, when the commas are at the beginning of the line they are really obvious. I have used commas-first style in JavaScript, and it definitely reduced the amount of times I forgot a comma.
I wonder if people's aversion to commas first has something to do with the fact that commas have a very familiar use in ordinary writing, and there they always follow a word. It is very common to see BNF grammars written with leading vertical bars, and no one seems to mind that -- in fact it would be unusual to use trailing vertical bars.
By the way, a bunch of languages permit a trailing comma after the last element of a list. This is also nice because it means that if you put each list item on a line, the list items all have the same format (thing plus comma). With the Haskell syntax, you lose this, but there is no reason a language couldn't support a leading comma before the first element of a list.
My aversion has to do with the fact that the first element doesn't have one. The irregularity is annoying not just aesthetically, but also if you want to swap lines around, etc.
But there's always a line without a comma -- comma-last has it on the last line instead of the first. So you can have the same line-swapping problem in either arrangement. Comma first just makes it easier to spot.
Not if you allow dangling commas (trailing commas as the sibling comment calls them, I think it's the more generic term)...
Then you have a comma at the end in ALL lines, including the last one, without an issue. That was what I proposed above (and lots of languages do it, I think JS is adding it too).
It's another thing to learn, and the total learning curve is the product of all of these idiosyncrasies (and features) (not the sum). And there's absolutely no advantage to comma-first.
This is only true if you insert at the head. And it's not really leading comma placement but the choice to put the first element in the line with the brace that is the culprit, though both are typical of comma-first.
With separating comma, it either affects the first or the last position, depending on where you put the commas. But those are the most common places you modify lists.
Hi, author here. While I agree that the language could be improved, I wonder why you say that this makes it uglier, and how you'd imagine a better solution (this is still in development, and any idea is welcome).
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
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).
Very strongly agreed. Syntactically significant whitespace is the source of so many preventable errors that I believe it's simply not worth the aesthetic improvements.
Keep in mind that I am being simultaneously irreverent while also expressing how I feel about these two debates (semicolons and significant whitespace).
I'm someone who has worked in a large variety of languages, including Python (significant whitespace) and Javascript (no significant whitespace).
First: semicolon inference in Javascript is an abomination :). If the language says that whitespace is not significant, then using newlines to infer where semicolons maybe should be... is inconsistent with the statement "whitespace is insignificant".
Second: when I learned Python, I was coming from a primarily Perl and C background. The significant whitespace wasn't a big deal at all because that's how I indent my code anyway. And I would argue (and do in code reviews) that any code that is not indented properly is incorrect because it is extraordinarily misleading to a reader.
So, yeah, for any given programming language, I couldn't care less if whitespace is significant or not, or whether there's semicolons at the end of lines, but god damnit don't go half way on either of those. Indent your code as if whitespace is significant (because it IS to whoever's trying to decipher it later), and stick semicolons at the end of your lines whether or not some stupid inference rule will stick them there for you if you forget.
And as a final rant, "modern Javascript" didn't introduce semicolon inference; it's been there for a long time and was put there to try to lower the barrier for newbies. It wasn't put there because it's a great design decision.
I come from Scala, and there semicolon inference works flawlessly. Why do you consider it to be an abomination in Javascript? (Except this famous corner case with continued line, almost never encountered in practice).
Things like this[1] are why I dislike semicolon inference. I very much think in language grammars, and languages that do clever things on top of that tend to annoy me. And, yes, I realize significant whitespace is likely implemented as a an edge case outside of the grammar, but it's at least simple.
An interesting thing with Scala is that in the BNF, "semi" is defined as ';' or nl.[2] After doing some initial reading about Scala, I was pretty much wondering why Scala needed semicolons at all. What you call "semicolon inference" seems like it's more like "optional semicolons", in that the language doesn't really need them.
Well... This is a sort of whitespace sensitivity, and I don't really like it, because that means that some tokens may or may not be meaningful depending on the context, which increases the complexity of the syntax -- and syntax is probably the first thing that I think should be dumb simple and predictable.
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.
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)?
About the multiple versions, the problem with "classical" package managers is that you have to do some manual renaming to ensure that both versions won't be installed in the same place in the file-system, which is tedious and doesn't scale well. Furthermore you may encounter some problems because both will be visible at the same time if the packager isn't careful enough. For example, if a software X has a dependency of libfoo2.1 and you happen to have libfoo3.1 also installed, the installation script for X may use libfoo3.1 instead of libfoo2.1, in which case you risk to encounter bugs because X hasn't been tested against libfoo3.1.