Call for bikeshed -- break replacement in expression switch

[Alex Buckley]

Correction: `yield-value` is a hyphenated keyword. Specifically, a 
hyphenated contextual keyword, where each term is itself a unitary 
contextual keyword. This is discussed, with examples, in the JEP 
(https://openjdk.java.net/jeps/8223002).

Introducing `yield-value` as a hyphenated contextual keyword doesn't buy 
you much. Both `yield` and `value` would tokenize as identifiers 
everywhere, so that you can keep on subtracting your `value` variable 
and the result of your `value` method:

   `int x = yield-value +y;`
   `int x = yield -value(x);`

So, recognizing a hyphenated contextual keyword `yield-value` would 
still require careful reasoning about context, about as much as we're 
doing to recognize a unitary contextual keyword `yield`.

Alex

On 5/17/2019 8:40 AM, Remi Forax wrote:
> Hi Manoj,
> yield-value is not a hyphenated keyword, the left part of the right part
> as to be an existing keyword.
>
> Remi
>
> On May 17, 2019 2:55:14 PM UTC, Manoj Palat <manoj.palat at in.ibm.com> wrote:
>
>     Hi,
>     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:
>
>     -As Maurizio pointed out in
>     _https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001334.html_,
>     “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-
>     *Our view point*: 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.
>
>     -Alex, in the discussion here
>     _https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001338.html_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
>     _https://www.eclipsecon.org/na2014/session/jdt-embraces-lambda-expressions.html_“
>
>     *Our View point: *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.
>
>     - An additional input to this discussion is the proposal for
>     hyphenated keywords as described in
>     _https://openjdk.java.net/jeps/8223002_. “break-with” which was the
>     earlier proposed one, was one among these hyphenated keywords.
>     *Our View point: *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.
>     - 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 “*yield-value*” or
>     any other hyphenated keyword.
>
>     Regards,
>     Manoj.
>     Eclipse Java Dev.