# [
# 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, hOkay. 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.
b, c d, e f g, h basically unreadable because it's incorrect.
@aedt
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.
It doesn't matter much, the moment you learn the syntax you will parse everything mentally.
inc v
inc(v)
@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))"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)
then
echo(b, (c d), (e f g), h)
then
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 ;)
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
# 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:
f.read()
v.print()
t.makeChild()
a.value
x.asInt
treeNode.left
etc.