I am relatively new to Nim. The only major gripe I have is with the <if> syntax, enough so to go head to head with you folks :). Let me elaborate.
The colon in the <if ... : >:
The colon in the <else :>
If the <else> were consistent with the <if>, its syntax would be:
- if canDo1() :
- do1()
- else canDo2() :
- do2()
Here the <else> functions like an <elif>, making that redundant.
I suggest:
And, as Larry Wall discovered as his First Law of Language Redesign: Everyone wants the colon.
Recently there was another thread "Too many colons", but I do not gripe about the other uses of the colon, say in the case statement. This post is solely about the if-else construct, with the 3 suggestions reflecting a strong order of priority: do not implement the 3rd without approving 2nd first, and 2nd before 1st.
I am well aware a <then> instead of a colon (point 3) may be well be unfeasible. However you'll agree with me that, if ever, now is the time to change.
Are you aware that colon begins a block in Nim language,
and having colon after if else is makes it just consistent
with any other function/operator that would take a block
as argument?
That is only valid for the single line version and imho <do> serves the job better:
for i in range do etc
The fact is: indentation is the what makes the block, not the colon. People are smart enough to understand the similarity.
As many coding guidelines prefer the multi-line version, this is an important use case. The colon is a continuous pain.
Okay I got your point and I tend to agree that colons are superfluous in Nim.
P.S. Please use reStructuredText (see Syntax Cheatsheet link when you edit your post) for your code formatting.
var a,b,c,d : int
a = 0; b = 0
c =
if a == b:
#d = 5
19
else:
17
echo cI would expect that I could place a side effect (assignment to d) in the block following the if - but that would not compile.
Do not expect that Nim's syntax is going to be changed in a sweeping and not backwards-compatible way so close to the 1.0 release.
Also: Wadler's Law.
@Jehan, yes, I know this. Typically syntax related topics tend to be sensitive. But I believe there are real pain points here that may inpire a review of the design. As a newbie it is sufficient for me to voice my experience.
@Sixte: I don't quite get your example. I suppose you highlight the "c=" combined with an indent. Yes, the single-line version of that statement doesn't take a colon. But this does not seem to affect the case I am making. But I admit I lack a wider focus, and this may complicate implementation, so yes, it is important to bring this to the table.
c = if a == b: 19 else: 17requires the colon too, of course. My point was: (pseudo-code, not nim) in:
c = if a == b {d = 5; 19} else {17}you could place a side effect into the first {} (and you could eventually omit the second {} )
Anyway, you always need a separator after the cond. expression. I take this, the colon, as "Nim Style" It is o.k.
@Sixte Can you elaborate more about this, because I do not really feel convinced that we need the colon in your multi-line (1st) example. The main question is if removing colon will cause syntax ambiguity. My intuition tells me that we may have a problem splitting long condition expressions into few lines, e.g.:
if long_variable + another_long_variable +
third_long_variable > fourth_long_variable:
echo "Yes then were so long!"
Removing colon in such case would need compiler to determine that 2nd line is not block start using some kind of heuristics based on last token on 1st line and context.
The if statement needs a colon to signal that it is finished and doesn't continue on a new line
> The if statement needs a colon to signal that it is finished and doesn't continue on a new line
If you mean the parser needs, then no it doesn't, at least I can't find any example where it will break w/o colon on multiline if stmt. This was my original assumption, that removing colon in multiline statement will cause syntax ambiguity, but now after few discussions on IRC I believe it doesn't. But there is still hope that someone can give an example of such ambiguity to prove colon is necessary.
I am still thinking about cases when we use procs without parenthesis in if's condition, but so far haven't found any. Some of my initial idea expected tol break, but it doesn't:
if 1 > abs 1 +
abs 2 + 2
echo "abs?"
ono: If you mean the parser needs, then no it doesn't, at least I can't find any example where it will break w/o colon on multiline if stmt.
It's a visual indicator to people who read the code, not the compiler. If the way humans read code didn't matter, then all programming languages would have LISP syntax (which is essentially an AST dump). If it didn't matter, we would strip all our sentences of any punctuation that isn't required to eliminate ambiguity. Your paragraph above would read:
"If you mean the parser needs then no it doesn't at least I can't find any example where it will break w/o colon on multiline if stmt This was my original assumption that removing colon in multiline statement will cause syntax ambiguity but now after few discussions on IRC I believe it doesn't But there is still hope that someone can give an example of such ambiguity to prove colon is necessary"
The reason why Python got colons to indicate the end of an if etc. is that in the usability studies that accompanied ABC (Python's predecessor), users found it more readable. You may argue that because the ABC studies targeted primarily inexperienced programmers, you cannot generalize the result. At the same time, it's the only thing resembling a scientific result we have regarding readability. (And, of course, the fact that it's being used in Python makes it immediately familiar to a lot of people.)
My concern is mostly that currently, every few weeks somebody shows up and demands a syntax change because it' important to THEM, not because they have any objective evidence that it actually matters to programmers at large. It's optional colons now, it was a terminating end keyword a few weeks ago, it was braces before then. What's next? C-style variable declarations with the type before the identifier? You can't have them all. They are either mutually incompatible or may turn Nim into the second coming of Perl with no consistent syntax at all. I don't want a perfect syntax (which doesn't exist, anyway, because it's so subjective). I want a stable language, not a constantly mutating one.
I am all with Jehan here, there is IMHO a delicate balance between positive and negative effects going down towards minimalistic syntax. Lisp for example, ended up IMHO too minimalistic to be comfortable for most people, the code just turns into a "sea of parenthesis". Forth is the ultimate in minimalism I guess, its just a sequence of tokens, all structure of the code lies in knowing what the words do. Smalltalk has more structure in its syntax than Lisp, but still has a very minimalistic grammar where everything is an expression etc. You can however distinguish code blocks from other literals (compared to Lisp) and there is sequencing etc. Its often stated that Smalltalk managed to find a very good balance on this "scale of minimalism".
Many compare Nim with Python, but personally I think that's very much just skin deep. One can't argue that Nim has a minimalistic syntax, but in this particular case many of us think that the removal of colons removes an important visual indicator. You keep asking for technical arguments, as if only those should be considered, but that's the least issue here.
That said I am all for more people joining the community and taking the time to read and hack the compiler and to improve it (the error messages commits) etc, so even if I will violently defend the colons :) I would also like to express my appreciation of your effort.
@gokr: Thank you for your honest explanation. For me the reason of this discussion was to understand completely the grammar and Nim's parser. Giving right & clear distinction what is language philosophy and what are the consequences is in my opinion very important and should find its place in the FAQ (similar to cited Python's one). As you can see the author of this thread was wondering why colons, and at the very beginning the was no clear and thorough answer why given from colon's defenders.
Now I completely accept answer that such syntax is pure philosophical decision and it is has more to do with way human read the code than what the parser needs. I was missing clear indication of that.
I think there will be others raising same questions, and definitely what Nim authors should do is to state clearly the language philosophy, also telling what is right syntax, and also giving some examples of wrong syntax - with explanation why it is wrong, e.g..:
This is OK
if 1 + 1 +
1 > 1:
echo "hi"
This is wrong, because ...
if 1 + 1
+ 1 > 1:
echo "hi"
Altogether I think this is not wasted effort of mine, and as consequence there are 2 bug fix PRs waiting for review: https://github.com/Araq/Nim/pull/2566 https://github.com/Araq/Nim/pull/2565
Also I believe and hope we all have learnt some thing new about Nim :)
I wonder how you could recompile so quickly to perform your tests. How did you proceed? Did you recompile given the sources in the folders compiler, system etc.. with koch.nim?
Or did you exchange one or a few of the precompiled (precompiled to C) sources?
@Sixte Not sure if I understand you correctly, whether you are asking about recompilation of the Nim compiler itself or the test cases.
As for compiler, I keep pristine copy in /usr/local/nim/bin/nim where experiments are made with local repository's bin, either with bin/nim or bin/nim_temp (from koch temp).
As for the dev workflow, I use TextMate on OS X with some improved Nim.tmbundle see PR, and compiling given pgm is as easy like hitting Cmd+R (or other combos depending on use case).
Is it what you have asked about?