4 ms·

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 t

by regnat 9y ago

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 9y ago
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?
- tonyarkles 9y ago
  > 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 9y ago
    Just look: https://gist.github.com/atemerev/889806081ed8fcb77495666fac9930e5 https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...
    - regnat 9y ago
      I see. But that means using a whitespace-sensitive syntax, which some people (including me ;) ) don't really like
      - matrix 9y ago
        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 9y ago
        There is no significant whitespace in what I am offering; just semicolon inference at newlines (like in modern Javascript).
        regnat 9y ago
        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.
        tonyarkles 9y ago
        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.
- regnat 9y ago
  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 9y ago
    Here is the example where I just removed every semicolon. https://gist.github.com/atemerev/889806081ed8fcb77495666fac9930e5 https://gist.github.com/atemerev/889806081ed8fcb77495666fac9... For me, it looks infinitely better.
  - atemerev 9y ago
    (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).
ykler 9y ago
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 9y ago
  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
porker 9y ago
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.

by regnat 9y ago

atemerev 9y ago

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?

tonyarkles 9y ago
> 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 9y ago
  Just look: https://gist.github.com/atemerev/889806081ed8fcb77495666fac9930e5 https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...
  - regnat 9y ago
    I see. But that means using a whitespace-sensitive syntax, which some people (including me ;) ) don't really like
    - matrix 9y ago
      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 9y ago
        There is no significant whitespace in what I am offering; just semicolon inference at newlines (like in modern Javascript).
        regnat 9y ago
        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.
        tonyarkles 9y ago
        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.
regnat 9y ago
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 9y ago
  Here is the example where I just removed every semicolon. https://gist.github.com/atemerev/889806081ed8fcb77495666fac9930e5 https://gist.github.com/atemerev/889806081ed8fcb77495666fac9... For me, it looks infinitely better.
- atemerev 9y ago
  (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).

ykler 9y ago

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 9y ago
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

porker 9y ago

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.