Re: Yield as contextual keyword

To be clear, in the new approach, the lexeme `yield` is always tokenized as an identifier, and never as a keyword. Gavin has already changed the MethodName production so that it uses UnqualifiedMethodIdentifier rather than Identifier. And since MethodName is used by MethodInvocation (15.12), A

Re: Yield as contextual keyword

Even in expression context, unqualified yield could be tokenized as keyword (and hence produce a compile-time error). What do we loose? If it is a field, it can be qualified. If it is a local variable, it only presents source incompatibility, which can easily be fixed at next re-compile. The

Re: Yield as contextual keyword

Upon reflection, the simplest way out of this is to not go down the path of trying to identify tokens so that the lexer knows something about parsing, but rather follow the suggestion made by Dan earlier in this thread. To wit, we treat `yield` much like we treat `var`. It’s a "restricted identi

Fwd: Yield as contextual keyword

Sent from my MacBook Wheel Begin forwarded message: > From: Jan Lahoda > Date: May 27, 2019 at 6:18:41 PM GMT+2 > To: Amber Expert Group Observers , > Doug Lea , Brian Goetz > Subject: Re: Yield as contextual keyword > >> On 27. 05. 19 16:06, Doug Lea wrote: &g

Re: Yield as contextual keyword

On 5/27/19 11:24 AM, Brian Goetz wrote: > This is really two questions. We could have a non-ambiguous keyword (eg > break-from-expression-switch); that’s separate from the keyword vs operator > story. > > To the latter, I think the simple answer is: all existing control flow > operations (re

Re: Yield as contextual keyword

This is really two questions. We could have a non-ambiguous keyword (eg break-from-expression-switch); that’s separate from the keyword vs operator story. To the latter, I think the simple answer is: all existing control flow operations (return, throw, break, etc) are words. This does not s

Re: Yield as contextual keyword

I don't enjoy being the token curmudgeon here, but I find it increasingly hard to appreciate why a non-ambiguous choice (prefix "^") with precedence in related languages should be rejected in favor of one requiring context-sensitive grammar mangling with some known odd consequences. At the very l

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> On 24 May 2019, at 22:14, Tagir Valeev wrote: > > Also sections 16.1.7 and 16.1.8 are named identically. Probably > there's some mistake. Weird as it seems, it was deliberate, in the sense that 16.1.5 and 16.1.6 are currently named identically (they are the n-ary versions of the conditional

Re: Yield as contextual keyword

Sure the problem could be fixed in a number of ways, it's just not as straightforwards as adding a qualifier. I can also think up several ways to fix this locally (modifying just single line): ((Runnable)() -> yield(1)).run(); or switch(0) { default -> yield(1); } or even for(int i=0; i<1; yie

Re: Yield as contextual keyword

This one is fixable with a local-variable rename. I think that's a robust solution as long as the anonymous class is in a context where the local can be introduced nearby. We can perhaps find awkward contexts where the local cannot be introduced. I'm thinking of 'super(new Object() {…})' and fiel

Re: Yield as contextual keyword

A small remark: when we advice to qualify the `yield` call to distinguish it from YieldStatement, there's one corner case when qualification is impossible. I mean a nested class inside an anonymous class var x = new Runnable() { public void run() { new Object() { void foo() { y

Re: Yield as contextual keyword

Hello! On Sat, May 25, 2019 at 4:44 AM Alex Buckley wrote: > On the other hand, the space after `:` is sometimes desirous of an > expression, so tokenize `yield` as a identifier: (and it might be the > name of a local variable, so no way to qualify) > > - `for (String s : yield . f) ...` > > - `m

Re: Yield as contextual keyword

On 5/24/2019 1:19 PM, Tagir Valeev wrote: Hello! Answering myself The first token in a YieldStatement production is always preceded by one of these separator tokens: ;, {, }, ), or ->. Seems I'm missing something. Could you please illustrate in which case YieldStatement could be preceded by '

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

One more exotic case: System.out.println(switch(0) { default -> { do yield 1; while(false); } }); Looks legit as well, though incredibly strange. Here yield is preceded by the 'do' token. With best regards, Tagir Valeev. On Fri, May 24, 2019 at 7:25 PM Gavin Bierman wrote: > > A draft spec i

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Hello! Answering myself > > The first token in a YieldStatement production is always preceded by one of > > these separator tokens: ;, {, }, ), or ->. > > Seems I'm missing something. Could you please illustrate in which case > YieldStatement could be preceded by ')'? Nevermind. if(foo) yield ba

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Hello! > The first token in a YieldStatement production is always preceded by one of > these separator tokens: ;, {, }, ), or ->. Seems I'm missing something. Could you please illustrate in which case YieldStatement could be preceded by ')'? Also what about '->'? In lambda '->' is followed by an

Re: Yield as contextual keyword

> On May 23, 2019, at 5:51 PM, Alex Buckley wrote: > > This policy is "You can declare a method called `yield`, but you can only > invoke the method by using qualified invocation syntax." OK, great. > > Could the policy in SE 10 have been similar? -- "You can declare a type > called `var`, but

Re: Yield as contextual keyword

Right. So far we have only talked about the language spec and the meaning of programs. There is lots more that compilers and ides can do to help users steer away from the (actually quite small) puzzler zones. Sent from my iPad > On May 24, 2019, at 10:53 AM, Guy Steele wrote: > > >> On Ma

Re: Yield as contextual keyword

> On May 24, 2019, at 10:34 AM, Brian Goetz wrote: > > > var yield = 5; > > yield is lexed as an identifier, so this is a valid variable declaration > > var res = switch(yield) { > > yield is lexed as an identifier, so this is a valid switch operand > > > default -> yield + yield; >

Re: Yield as contextual keyword

var yield = 5; yield is lexed as an identifier, so this is a valid variable declaration  var res = switch(yield) { yield is lexed as an identifier, so this is a valid switch operand     default -> yield + yield; RHS of a single-consequence case is expression | block statement | throw.  We

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

A draft spec including the compromise strategy below is available at: http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html Comments welcomed! Gavin > On 22 May 2019, at 17:45, Brian Goetz wrote: > > We’ve been drilling i

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Also an interesting case: var yield = 5; var res = switch(yield) { default -> yield + yield; } // are we returning result of binary plus (10) or yielding result of unary plus (5)? Seems the first one, yet confusing. Tagir. On Fri, May 24, 2019 at 4:30 AM Dan Smith wrote: > > > On May 22, 2019,

Re: Yield as contextual keyword

On 5/23/2019 2:29 PM, Dan Smith wrote: 2) Type names: 'yield' might be used as the name of a class, type of a method parameter, type of a field, array component type, type of a 'final' local variable etc. Or we can prohibit it entirely as a type name. We went through this when designing 'var', a

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 23, 2019, at 2:29 PM, Dan Smith wrote: > > Are people generally good with my preferred restrictions, or do you think > it's better to be more permissive? In this case I prefer the restrictions because, again, it's a simpler user experience. The loss of the method name "yield" for an *un

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> On May 22, 2019, at 9:45 AM, Brian Goetz wrote: > > The “compromise” strategy is like the smart strategy, except that it trades > fixed lookahead for missing a few more method invocation cases. Here, we > look at the tokens that follow the identifier yield, and use those to > determine whet

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Right. Having a simple rule (“always qualify methods”) has a simpler surface, even if it isn’t maximally discriminating. That it is lookahead(2) also makes life easier for tools…. > On May 22, 2019, at 8:46 PM, Tagir Valeev wrote: > > Hello. > > I agree: compromise strategy is the best opti

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Hello. I agree: compromise strategy is the best option. It should be less surprising to users. E. g. consider that yield is a vararg method to produce several values at once. Use would be pretty surprised when removing an argument makes code incompilable. With best regards, Tagir Valeev. ср, 22

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

yes, i fully agree. Rémi - Mail original - > De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Mercredi 22 Mai 2019 18:12:03 > Objet: Re: Yield as contextual keyword (was: Call for bikeshed -- break > replacement i

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

+3.7 > On May 22, 2019, at 12:12 PM, John Rose wrote: > > On May 22, 2019, at 8:45 AM, Brian Goetz wrote: >> >> So my recommendation here is the compromise strategy. > > +10 Let's do it. > > Even though it fails to recognize some yield method > calls, it is easy to learn and explain and t

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 22, 2019, at 8:45 AM, Brian Goetz wrote: > > So my recommendation here is the compromise strategy. +10 Let's do it. Even though it fails to recognize some yield method calls, it is easy to learn and explain and therefore more predictable for end users. The failure to recognize is goi

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

We’ve been drilling into the spec and implementation of yield as a contextual keyword. We have three possible strategies, all of which are specifiable and implementable, but with tradeoffs. The “dumb strategy” would be to say that `yield` is a keyword when it appears in the first position of

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I discussed this with colleagues and can confirm that for IntelliJ IDEA parser it will be no problem to always consider yield as a statement. At least it's much easier than to consider it as a statement inside switchy blocks only. With best regards, Tagir Valeev. On Tue, May 21, 2019 at 12:38 PM

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

- Mail original - > De: "John Rose" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Lundi 20 Mai 2019 22:00:43 > Objet: Re: Yield as contextual keyword (was: Call for bikeshed -- break > replacement in expression switch) &g

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> So does this (option B plus your No) mean that IDEs would tend to color > "yield" as a keyword (at the beginning of a statement) even if followed by > "("? My "No" was mostly against options C and D where symbol resolution affects the parse tree. Sorry if it wasn't clear from my message. When

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

For the record: I checked IDEA Ultimate source code (>10 of Java files, total size is about 400Mb). It appears that an unqualified call of the method called 'yield' as an expression statement is used only once accross our sources: https://github.com/JetBrains/intellij-community/blob/34e0721dca3

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Okay, with this more detailed explanation and understanding, I am back in the `yield` camp. But I’m glad to have explored that side path just a bit. > On May 20, 2019, at 3:51 PM, Brian Goetz > wrote: > > Clarification on Option (B): the rational thing to do is p

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 12:51 PM, Brian Goetz wrote: > > The cost-benefit analysis rests on the assumption that this will bite > exceedingly rarely, and when it does, the workaround will be clear and easy. OK, so let's road-test "yield". While "break: x" is syntactically safer than "yield x", I b

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 8:24 AM, Tagir Valeev wrote: > > Assuming that we agreed on 'yield' the option B seems the most attractive. A > big No to context-specific parse tree. It's a complete pain to IDEs. Don't > forget that IDE often deals with incomplete code, missing dependencies, etc., > and s

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Clarification on Option (B): the rational thing to do is probably not to restrict this behavior to switchy blocks, because there are other kinds of statement contexts that will be embedded in switchy blocks, such as: case L -> { if (cond) yield e; } And surely we wa

Re: Yield as contextual keyword

On 5/20/19 1:02 PM, John Rose wrote: > On May 20, 2019, at 9:06 AM, Guy Steele wrote: >> >> under this theory a plausible spelling of `break-with` is `break:` > > FWIW I'd be very very happy with the look/feel of `break: x;`. > Almost the same here. Subtract a few verys, keep the happy. -Doug

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

On May 20, 2019, at 9:06 AM, Guy Steele wrote: > > under this theory a plausible spelling of `break-with` is `break:` FWIW I'd be very very happy with the look/feel of `break: x;`. I'd be a little happier with `break->x` because I'm used to reading expressions `x` in `->x` but not so much `:x`.

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> On May 20, 2019, at 12:16 PM, Brian Goetz wrote: > >> But I now think that this argument is weak, because I believe it is in fact >> unlikely that there will be a large number of other statement types that we >> will want to turn into expressions. >> >> * Yes, we may want block expres

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

> But I now think that this argument is weak, because I believe it is in fact > unlikely that there will be a large number of other statement types that we > will want to turn into expressions. > > * Yes, we may want block expressions. > * We would want `if`-statement expressions _ex

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I am becoming more worried again about the consequences of using a contextual keyword such as “yield”, especially for IDEs. It seems to me that this whole discussion kicked off with a discussion of `yield` as being desirable because, by analogy with `return` being the One True Way to return a v

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Hello! Assuming that we agreed on 'yield' the option B seems the most attractive. A big No to context-specific parse tree. It's a complete pain to IDEs. Don't forget that IDE often deals with incomplete code, missing dependencies, etc., and still needs to provide reasonable highlighting and comple

Re: Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I would vote for option E - a real keyword : break-with. Regards, Manoj From: Guy Steele To: Brian Goetz Cc: amber-spec-experts Date: 05/18/2019 12:11 AM Subject:[EXTERNAL] Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I (somewhat reluctantly, but with an appreciation for the pragmatics of the situation) support option B. —Guy > On May 17, 2019, at 12:57 PM, Brian Goetz wrote: > > As was pointed out in Keyword Management for the Java Language > (https://openjdk.java.net/jeps/8223002 >

Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

Thanks for providing a clear view of our options. I vote for B. I will add that obviously there is no switchy block that contains an unqualified yield in the actual code so the compiler should emit an error instead of a warning if there is an unqualified yield in the scope of the switchy block.

Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

As was pointed out in Keyword Management for the Java Language (https://openjdk.java.net/jeps/8223002 ), contextual keywords are a compromise, and their compromises vary by lexical position. Let’s take a more organized look at the costs and options for do