why brackets & commas in func calls can't be ommited? (maybe it could be PEP?)

[Steven D'Aprano]

On Wed, 21 Mar 2007 07:55:08 -0700, dmitrey top posted:

> I think it should result

What's "it"? Please don't top post, it makes your answer hard to
understand and makes your readers have to do more work to read your posts.
We're not being paid to read your posts, so I'd estimate that about 70% of
readers have just clicked "Delete" at this point and ignored you.

For those remaining:

The Original Poster, dmitrey, wants to copy caml syntax, because he
doesn't like brackets and commas.

The problem is that the expression:

name1 name2

is ambiguous. Does it mean name1(name2) or (name1, name2)? Add a third
name, and the ambiguity increases: there are now at least four ways to
interpret name1 name2 name3:

(name1, name2, name3)
(name1, name2(name3))
name1(name2, name3)
name1(name2(name3))

Dmitrey thinks that the third way is the "right" way to interpret the
proposed expression, just because it seems natural to him. But that is
illogical: it means that *different* parsing rules are applied to the
"name2 name3" part than to the "name1 *" part (where "*" stands in for
anything):

Dmitry wants "name1 *" to equal name1(*) which is fair enough as it
stands. But he wants to expand the * part, not by following the same rule,
but by following the different rule "name2 name3" => (name2, name3) and
form a tuple.

So what should "a b c d" be? 

(a, b, c, d)
a(b, c, d)
a(b, (c, d))
a(b(c, d))
a(b(c(d)))

Have I missed anything? Which is the "right" way? Who can tell?

Who can guess?

I don't know how caml resolves these ambiguities, or even if caml resolves
them, or if it is a good solution. But I propose that an even better
solution is to insist on EXPLICIT function calls and tuple construction,
that is to insist on brackets and commas.

In other words, to go back to Dmitry's original post where he wrote:

"it would reduce length of code lines and make them more readable"

I would change that to say "it would reduce length of code lines and make
them LESS readable and MORE ambiguous, leading to MORE bugs".


-- 
Steven.