Call for bikeshed -- break replacement in expression switch

Remi Forax forax at
Fri May 17 22:38:40 UTC 2019

Thanks, Alex, i stand corrected.


----- Mail original -----
> De: "Alex Buckley" <alex.buckley at>
> À: "amber-spec-experts" <amber-spec-experts at>
> Envoyé: Vendredi 17 Mai 2019 23:56:14
> Objet: Re: Call for bikeshed -- break replacement in expression switch

> 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
> (
> 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> 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
>>     _,
>>     “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
>>     _
>>     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
>>     _“
>>     *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
>>     _ “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.

More information about the amber-spec-observers mailing list