<p dir="ltr">Can you walk me through how this simplifies the grammar etc in concrete compare contrast or what the diffs between the grammar and associated engineering would be?  </p>
<p dir="ltr">I don't see how it simplifies the grammar, but I could be a bit obtuse.  </p>
<p dir="ltr">That aside, I'm also a bit fuzzy on the other claim, that this change will simplify post parsing engineering,  </p>
<div class="gmail_quote">On Jul 7, 2016 4:47 PM, "Jon Purdy" <<a href="mailto:evincarofautumn@gmail.com">evincarofautumn@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> ambiguity is bad for humans, not just parsers.<br>
<br>
This is not ambiguous. It’s removing the need for a redundant set of<br>
parentheses, whichever way you slice it. Of course, some redundancy is<br>
useful for readability (look at natural language), but you should<br>
really be explicit if you’re arguing from that position.<br>
<br>
> perhaps most damningly,<br>
>><br>
>><br>
>> f do{ x } do { y }<br>
><br>
><br>
> is just reallly really weird/confusing to me<br>
<br>
By “weird”, do you mean anything other than “I don’t understand it,<br>
and I blame it”? Can you give an example of how you might misparse it,<br>
as a human reader?<br>
<br>
>> It's harder to read than the alternative.<br>
>><br>
>> Creating a language extension to get rid of a single character is overkill<br>
>> and unnecessary.<br>
<br>
It’s only a language extension for backward compatibility. It’s really<br>
fixing a bug in the grammar.<br>
<br>
> I'm all in favor of doing engineering work to *improve*<br>
> our parser error messages and suggestions, but not stuff that complicates<br>
> parsing for humans  as well as machines<br>
<br>
This would be a simplification of the parser if the bug hadn’t been<br>
standardised originally.<br>
</blockquote></div>