<div dir="ltr"><div dir="ltr">Am Mi., 16. Juni 2021 um 08:47 Uhr schrieb Li-yao Xia <<a href="mailto:lysxia@gmail.com">lysxia@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] - An ambiguous grammar may be more readable (since there are strictly <br>
more choices available), especially if you care more about the AST than <br>
the concrete syntax. [...]<br></blockquote><div><br></div><div>IMHO it is exactly the other way around: I consider ambiguous grammars a serious usability bug. Even if you hack around the ambiguities via meta rules and/or technical tricks like "prefer shift" in (LA)LR parsers, you as a poor human have to do the disambiguation for yourself. This makes it *harder* to read code following the grammar, not easier. The BlockArguments proposal introduced lots of additional ambiguities, and that's the reason why I'm still opposed to it. I'm too lazy to dig out the old discussions, but I gave a few examples where it was *highly* unclear/confusing what the right parse should be with BlockArguments. This has been totally ignored, and that ship has sailed...</div><div><br></div><div>In general, I consider it a very bad idea to give more and more strings a meaning as a program: Some redundancy, like keywords and/or punctuation, is highly useful as a human reader. Remember the old saying "A good language should not make it easy to write correct programs, it should make it hard to write incorrect ones", and BlockArguments was IMHO a step into the wrong direction.</div></div></div>