# [
# sugar  ==  meaning ==> my personal opinion
# f a    ==  f(a)    ==> Please don't. It creates confusion and people can live without it. It's better not to keep hidden corners.
# a.f()  ==  f(a,b)  ==> Fantastic. Though you can argue about it being confusing (member functions etc).
# a f    ==  f(a)    ==> Functions are first class citizens. I don't know if I like this.
# f a, b ==  f(a,b)  ==> Please, no more confusion.
# a.f(b) ==  f(a,b)  ==> I love it.
# a.f    ==  f(a)    ==> I don't like it. It reminds me of Class variables.
# a.f b  ==  f(a, b) ==> Guaranteed confusion further down the road. Makes it impossible to chain functions.
# ] 

Why allow ambiguous constructs? For example in C, where int arr[5] is declared, 3[arr] == arr[3] is true. It doesn't make sense, although the explanation is simple. However

 b, c d, e f g, h
is basically unreadable.

2017-07-13 03:41:36

Okay. Note that all this is entirely subjective and I do not claim that any of this is in some way, shape, or form superior to what others prefer.

# f a    ==  f(a)    ==> For commands and templates/macros that emulate control structures and such. For functions that return values, f(a).
# a.f()  ==  f(a)    ==> I don't use it. Unnecessary parentheses hurt readability. Note that in languages such as Eiffel, this is normal.
# a f    ==  f(a)    ==> Umm, this doesn't work?
# f a, b ==  f(a,b)  ==> Same as above for "f a". For commands, not for functions.
# a.f(b) ==  f(a,b)  ==> Whenever I'm calling what is conceptually a method.
# a.f    ==  f(a)    ==> Ditto. See above about Eiffel. Uniform Access Principle.
# a.f b  ==  f(a, b) ==> Use it only very, very rarely for operator-like syntax, e.g. "a .plus b".

I'm not religious about any of this. Sometimes having spaces instead of parentheses or vice versa can help with making a long line more readable.

2017-07-13 07:01:59

b, c d, e f g, h basically unreadable because it's incorrect.


In my case, see the comma position, each of its space should be evaluated or transformed (whatever the operation). If compiler cannot see what you intended, it means you're coding it incorrectly and you'll need to use parenthesis anyway.

Since I mostly look at the result of the expression, the syntax doesn't matter for me much.

2017-07-13 07:39:49

It doesn't matter much, the moment you learn the syntax you will parse everything mentally.

inc v

2017-07-13 08:04:26

@Jehan, Hmm, it seems like I was incorrectly applying UFCS rule. a.f = f a = a f (which is wrong and it's clear to me now)

@mashingan, "echo b, c d, e f g, h" could be compiled as echo

(b, c(d, e(f(g,h))))
(b, c(d, e(f(g), h)))
(b, c(d), e(f(g), h))
... etc, no? That's what I meant. I know it would confuse the user not the compiler but still..

2017-07-13 08:39:16
@aedt: Nim belongs to a select group of languages that give you plenty of options and then get out of your way and let you code the way you want to. What may be ambiguous to you and me may be perfectly readable to someone else. Nim treats us like adults: it gives us the power and flexibility to write 'ambiguous constructs' if we so wish. It's up to us to wield that power responsibly.
2017-07-13 08:50:25

"echo b, c d, e f g, h" could be compiled as (arguments for) echo

Now it's understandable, when you wrote it start only from b.., so I didn't know what it was for.

Basically you read it like this

echo(b, c d, e f g, h)


echo(b, (c d), (e f g), h)


echo(b, (c(d)), (e(f, g)), h)

Please note that between ..., e f g,... could become like this

echo(b, (c(d)), (`f`(e, g)), h)

depends on what each letter represents.

From my point of view, I can see it clearly, have you seen it clearly now?

PS: I'm not against parenthesis since I was used to read Lisp code, but I wasn't really a Lisper because I usually omitted parenthesis whenever I can

2017-07-13 09:29:22

hmm, I am a bit surprised, I would have guessed the following parsing rule:

echo b, c d, e f g, h
  echo(b, c(d, e(f(g, h)))) # <--- I expected this
  echo(b, c(d), e(f(g)), h) # but hey it's this

2017-07-14 02:15:17

 # a.f()  ==  f(a)    ==> I don't use it. Unnecessary parentheses hurt readability. Note that in languages such as Eiffel, this is normal.

personally, I like the Scala convention:

  • if it does side effects, and/or mutate state, then use parens:


  • otherwise, if it's equivalent to a field and/or processing time is negligible, drop the parens:



2017-07-14 13:03:00