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 <[email protected]> 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.
