Call for bikeshed -- break replacement in expression switch
forax at univ-mlv.fr
Fri May 17 22:38:40 UTC 2019
Thanks, Alex, i stand corrected.
----- Mail original -----
> De: "Alex Buckley" <alex.buckley at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> 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`.
> 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.
>> On May 17, 2019 2:55:14 PM UTC, Manoj Palat <manoj.palat at in.ibm.com> wrote:
>> 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 , and everything
>> worked out, so I don't see why the language should disallow any of
>> John's examples” where The reference  is “ See slides 9-11
>> *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.
> > Eclipse Java Dev.
More information about the amber-spec-observers