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 there a possibility to infer them?

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

Here is the example where I just removed every semicolon.

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

For me, it looks infinitely better.

> 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

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.

There is no significant whitespace in what I am offering; just semicolon inference at newlines (like in modern Javascript).

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.

[1]https://stackoverflow.com/questions/29743009/in-scala-are-se... [2]https://github.com/jystic/language-scala/blob/master/doc/syn...

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

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