It can be parsed but you cannot reliably format it.
IDEA with its powerful formatters frequently struggles to properly format either of them, resulting in invalid code.
IDEA with its powerful formatters frequently struggles to properly format either of them, resulting in invalid code.
So it's not ambiguous.
> IDEA with its powerful formatters frequently struggles to properly format either of them, resulting in invalid code.
IDEA (by now) does very stupid things while trying hard to be smart. Also it's full of bugs. I stopped to use it because of all those annoyances.
It is. you can parse something given how it's indented. Doesn't mean that the resulting code is actually correct (from the logic point of view). And you cannot properly format it because the logic is ambiguous.
Both of these are valid code. One (or both of them) are incorrect
if x > 0:
function1()
function2()
function3()
if x > 0:
function1()
function2()
function3()
db:
mysqldatabase:
hostname: localhost
port: 3012
username: root
password: root
> IDEA (by now) does very stupid things while trying hard to be smart.
This is beside the point.
Exactly
> it simply has to infer the semantic meaning of both, which is
How exactly do you want the parser for the formatter to "infer semantic meaning"? It has no knowledge of the human requirements for this code. To the parser both are valid
> Both programs should be expressible in any language hence I don't see why you are placing the onus on the compiler to tell you one is incorrect.
Are we talking about "expressible in any language"? No.
Here's what I wrote: "Formatters will no save you from the many, many, many cases where indentation is simply ambiguous" in the context of formatters.
if x > 0:
function1()
function2()
function3()
if x > 0:
function1()
function2()
function3()
Please show two or more possible ways to parse this code, as I still don't see it.
I see in each case only one way to parse the examples.
An ambiguity in parsing is something like that (in e.g. C++): `a<b>(c)`.
You could read it as an boolean expression `(a < b) > c` or as a call to a templated function `a<TemplateParam>(someType param)`.
But there is only one way to read the above code, imho.