[regnat]

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

[atemerev]

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?

[regnat]

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 ?

[atemerev]

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

[atemerev]

Here is the example where I just removed every semicolon.

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

For me, it looks infinitely better.

[tonyarkles]

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

[atemerev]

Just look:

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

[regnat]

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

[matrix]

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.

[atemerev]

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

[porker]

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.

[ykler]

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

[regnat]

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