Call for bikeshed -- break replacement in expression switch
alex.buckley at oracle.com
Fri May 17 21:56:14 UTC 2019
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