# [ # 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 is declared, 3[arr] == arr is true. It doesn't make sense, although the explanation is simple. However
b, c d, e f g, his basically unreadable.
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.
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.
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))))or
(b, c(d, e(f(g), h)))or
(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..
"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
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:
- if it does side effects, and/or mutate state, then use parens:
f.read() v.print() t.makeChild()
- otherwise, if it's equivalent to a field and/or processing time is negligible, drop the parens:
a.value x.asInt treeNode.left