<html><body><p><font face="Courier New">Hi,</font><br><font face="Courier New">I have a few points regarding this – since there was a flurry of mails last night/day, I have given references below to specific threads below:</font><br><br><font face="Courier New">-As Maurizio pointed out in </font><a href="https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001334.html"><u><font color="#602162" face="Courier New">https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001334.html</font></u></a><font face="Courier New">, “yield†is not really a _reserved_type_identifier_ like “var†– “var†is correct only at places (at some places actually) where a type can occur- </font><br><b><font face="Courier New"> Our view point</font></b><font face="Courier New">: At parsing time “var†is just taken as a type and hence from a compiler implementation point of view, “var†is less of a challenge than the proposed “yieldâ€. If “yield†value is used instead of “break†value, then again, the compiler needs to disambiguate – the disambiguation problem just manifests in a different avatar.</font><br><br><font face="Courier New">-Alex, in the discussion here </font><a href="https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001338.html"><u><font color="#0000FF" face="Courier New">https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001338.html</font></u></a><font face="Courier New"> has pointed out that “The parsing of a `(` token has triggered potentially unbounded lookahead for some time [1][2], and everything worked out, so I don't see why the language should disallow any of John's examples†where The reference [1] is “[1] See slides 9-11 from </font><a href="https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html"><u><font color="#602162" face="Courier New">https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html</font></u></a><font face="Courier New"> “ </font><br><b><font face="Courier New"> Our View point: </font></b><font face="Courier New">However, though the problem was resolved finally for lambda, additions of new context sensitive keywords would make our parsing more complicated with additional logic in lookaheads. Although the problem was solved from a pure compiler perspective, we are far from winning the battle as an IDE where one major value add is code completion, which works on incomplete code. Due to these hacks, code completion for lambdas still has unresolved issues for us.</font><br><br><font face="Courier New">- An additional input to this discussion is the proposal for hyphenated keywords as described in </font><a href="https://openjdk.java.net/jeps/8223002"><u><font color="#602162" face="Courier New">https://openjdk.java.net/jeps/8223002</font></u></a><font face="Courier New">. “break-with†which was the earlier proposed one, was one among these hyphenated keywords. </font><br><b><font face="Courier New">Our View point: </font></b><font face="Courier New">We are fine with that as mentioned in the mailing list sometime earlier in the context of switch expressions and break-with, the hyphenated keyword. The more the number of context sensitive keywords are introduced, causing more hacks, it would be really difficult to sustain and scale the Eclipse IDE. </font><br><font face="Courier New">- Based on the above, I believe “break-with†was a better candidate with less or disambiguation and it goes along with the future direction of keywords. Here the assumption is break-with is not context sensitive at any point in time. Given that “break-with†had opposition, and “yield†was more popular candidate, planning to reply with a new suggestion of hyphenated keyword “</font><b><font face="Courier New">yield-value</font></b><font face="Courier New">†or any other hyphenated keyword.</font><br><br><font size="2">Regards,</font><br><font size="2">Manoj.</font><br><font size="2">Eclipse Java Dev.</font><br><br><img width="16" height="16" src="cid:1__=EABB096EDFC256808f9e8a93df938690918cEAB@" border="0" alt="Inactive hide details for Remi Forax ---05/17/2019 01:00:23 PM-------- Mail original ----- > De: "John Rose" <john.r.rose@oracl"><font size="2" color="#424282">Remi Forax ---05/17/2019 01:00:23 PM-------- Mail original ----- > De: "John Rose" <john.r.rose@oracle.com></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Remi Forax <forax@univ-mlv.fr></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">John Rose <john.r.rose@oracle.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">amber-spec-experts <amber-spec-experts@openjdk.java.net></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">05/17/2019 01:00 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: Call for bikeshed -- break replacement in expression switch</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"amber-spec-experts" <amber-spec-experts-bounces@openjdk.java.net></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">----- Mail original -----<br>> De: "John Rose" <john.r.rose@oracle.com><br>> À: "Brian Goetz" <brian.goetz@oracle.com><br>> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net><br>> Envoyé: Vendredi 17 Mai 2019 08:41:20<br>> Objet: Re: Call for bikeshed -- break replacement in expression switch<br><br>> (Going back to the start of this thread.)<br>> <br>> On May 12, 2019, at 12:38 PM, Brian Goetz <brian.goetz@oracle.com> wrote:<br>>> <br>>> We could surely take “break-with†and move on; it feels sufficiently “switchyâ€.<br>> <br>> If "break L" breaks out of a statement introduced with "L"…<br>> <br>> Then…<br>> <br>> "break ->" could break out of a statement introduced with "->".<br><br>It's not logical for me, it's not "L", it's "L:".<br>If it was "break :L", i would agree.<br><br>Rémi<br><br></font></tt><br><br><BR>
</body></html>