But as I said, I have to look at your post more carefully later.
o_O
Your sloppy use of extraneous grouping, discussed below, to show anything about the ':' character is foolish and a waste of that time available.
I spent about fifteen minutes responding, but I'll gladly stop posting before responding to another such bit of nonsense.
The grammar does not make the separation for good reason.
The reason being that the ':' doesn't bind with the block in either event.
When you went to be more explicit about that separation and broke the 'or', you introduced ambiguity,
Code:
A1: simple_stmt
A2: A1
A3: NEWLINE
A4: A3 INDENT
A5: A4 stmt+
A6: A5 DEDENT
A7: A6
suite: A2 | A7
The grammar hasn't been augmented. I've not introduced any sort of ambiguity.
Your an idiot if you think separation introduces the ambiguity.
which could only be resolved by introducing a new branch.
When you choose to bind the ':' as being part of the block, you introduce ambiguity.
An ambiguity, by the way, that isn't resolved by intruding a new branch.
But that says nothing about nested code, which is defined one branch up in the parser.
Correct. Nested code, a compound statement, has nothing to do with a block statement which is a block of statements.
We've been talking about block statements ("Technically it is not true that Python doesn't impose a block delimiter. That delimiter exists and it is obligatory. It's the colon you see in the code snippets above.") the entire time so I'm not sure why you've brought up compound--"nested code"--statements.
In any event, you are definitely still wrong if you think the ':' character is the "open compound-statement" delimiter.
Code:
while(a): if(b): a = c() else: a = d()
You aren't seeing three compound statements--"nested code"--delimited by a ':' character.
You are seeing one--"nested code"--compound statement. You see a while-branch statement and a if-branch statement with the option "else" clause.
You do indeed see two simple statements, but the ':' character isn't either a "open simple-statement" delimiter.
Your use of the "nested code" rule doesn't say anything, more below, about the ':' character.
Meanwhile, the following is perfectly valid python code:
The following C++ code is perfectly valid:
Code:
if(((((((((((((((((((((((((((((((true)))))))))))))))))))))))))))))));
The code can be simplified by removing the extraneous grouping tokens:
I can't remove either the '(' or the ')' character. The remaining '(' and ')' characters are part of the `if' itself.
But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.
A language allowing almost arbitrary extraneous grouping tokens doesn't change the delimiter requirements or binding for any characters required as part of a rule.
The following is a valid Python program:
Code:
(((((((((((((((((((((((((((((((True)))))))))))))))))))))))))))))))
The code in the example is also valid as a condition statement.
Code:
if(((((((((((((((((((((((((((((((True))))))))))))))))))))))))))))))): pass
The code can be simplified by removing the extraneous grouping tokens:
I can't remove ':' character. The ':' character is part of the `if' itself.
The parser travels through suite and into simple_stmt branch to parse the print() statement. It's important to note the order.
Okay...
The parser uses the if_stmt rule to parse the "if" fragment before moving onto the test rule which allows for extraneous grouping tokens through combining other rules which themselves allow for extraneous grouping tokens before moving onto the ':' fragment which neither delimits the test rule or suite rule being part of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT component before moving onto the "else" fragment before moving onto the ':' fragment which still doesn't delimit the suite statement being part of the "else" component of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT fragment.
It is very important to note the order.
But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.
Congratulations. You wrapped the condition in parenthesis.
You very effectively showed that the option grouping tokens you added are extraneous.
You've killed the idea that wrapping a condition in extraneous parentheses changes the meaning of a sentence.
The following is also valid Python code:
Code:
if True:
(print(True))
else:
(print(False))
The example shows that the option grouping tokens I added are extraneous.
The example says literally nothing about the ':' character.
*shrug*
I also never said "the idea that ':' behaves more like an open parenthesis", but I'm pretty sure that a mistype.
Soma