||| ...
||| Some examples where parentheses *are* required:
|||
||| (if 1 then 2 else 3) + 4
|| But that's because it's a top-level expression beginning with "if", not
|| because of the "+", right? In the patched Python, this works fine:
||
|| >>> x = if 0 then 2 else 3 + 4
|| >>> x
|| 7
|| >>>
| But it groups differently: the 'else' part is '3 + 4' here. Try 'if
| 1'. :-)
Yes, I understand how it groups, and am fine with it. The question I asked
is the one I asked <wink>: the paretheses aren't required because of the
"+", but solely because it's a "top-level expression". This is by way of
contrast with the example that was next to it in the original:
a[(if i then 2 else 3) : 4]
where, unlike the "+" example, the parens are also required if you stick
that on the RHS of an assignment.
I thought both were *intended* to be examples of:
you need to add parentheses to disambiguate expressions:
...
- if the conditional expression is to be combined with a unary or
binary operator.
as "+" and ":" both feel like <wink> binary operators in these examples.
|| OTOH, these seem odd:
||
|| >>> 4 + if 1 then 2 else 3
|| File "<stdin>", line 1
|| 4 + if 1 then 2 else 3
|| ^
|| SyntaxError: invalid syntax
> That's too much work for the parser to get right. And you'd get
> anomalies like
>
> 3 * if 1 then 2 else 3 + 4
>
> -- how should this group?
That's a good point.
> ...
> Because the conditional *ends* in something that "pulls in" all
> following binary operators and their operands until it hits a ")",
> I find it safer not to let it accept an operator at the front.
I agree. The "precedence pull" of "*" does make it more tempting to misread
x = 3 * if 1 then 2 else 3 + 4
than to misread
x = if 1 then 2 else 3 + 4
and I'm personally happier with "excess" parentheses anyway.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4