<div dir="ltr"><div class="gmail_default" style="font-family:monospace">
<div style="font-family:monospace" class="gmail_default">(copying my message here since I responded to the wrong thing)</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Hello Brian,<br><br>Thank you for your response.<br><br>> As you point out, this isn’t really about `when`<br><br>Guilty as charged.<br><br>I
see contextual keywords as a tactic that is useful when there is a
phrase that is so expressive/useful that it is worth the costs I
mentioned in the original post. There's definitely a time and a place
for them. However, I also feel like the budget for that has been mostly
exhausted already, and that from here on out, I'd like us to move away
from this tactic.<br><br>> if we did as you say for `when`, you’d write exactly<br>> the same mail the next time we consider a contextual<br>> keyword.<br><br>To
be clear, I certainly didn't and do not intend to raise this point
again without something major changing. I just felt like now was a
useful time to bring up this discussion because "when clauses" are in
preview.<br><br>Also, I get the feeling that the keyword decision made
here will likely set the tempo for keyword choices moving forward. For
example, it looks like we'll all be seeing a lot more "switches" in
Java's near future. So if "when clauses" are received well, I am pretty
certain that people will use them as evidence to support using more
contextual keywords in the future. You can imagine my concern.
Therefore, I'd like to catch it now while it's still within reach.<br><br>> but others reading this exchange may not have (read <br>> the JEP Draft)<br><br>Thank you for pointing this out. I agree, and I will also provide a brief summary here too.<br><br>In
short, this JEP Draft takes advantage of 3 facts and combines them
together to create a new way to generate new Java keywords that are NOT
context-dependent.<br><br>First, there are "classic keywords" in Java that can NEVER be used as an identifier. Here are a few.<br><br>final<br>int<br>double<br>if<br>case<br><br>Second, the hyphen (-) in Java is currently used to denote subtraction (ignore the "non-sealed" keyword for now).<br><br>Third, you can ONLY perform subtraction upon identifiers, NEVER on "classic keywords".<br><br>Therefore,
if you combine these 3 facts, you can use the following strategy to be
able to create new keywords. The official name the JEP used is
"Hyphenated classic keywords".<br><br>If you make a keyword like <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">"record-class"</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">"record" is considered a valid identifier, but "class" can NEVER be a valid identifier. <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Therefore, if we follow the pattern of <br></div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">IDENTIFIER --> HYPHEN --> KEYWORD</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">you
can generate all sorts of keywords that are NOT context-dependent. This
allows all the language parser folks to simply look for a "classic
keyword", see if it is followed by or following a hyphen, then check for
the permitted "Hyphenated classic keywords". <br><br>And to be clear,
the JEP Draft also suggests other strategies as well that instead use
context-dependent concepts. I am not talking about those, only the
paragraph of the JEP Draft titled "Hyphenated classic keywords".<br><br>> Whenever we consider new language syntax, we are <br>> called upon to make tradeoffs between many <br>> considerations<br><br>This
was very informative, thank you. I had soft concepts for all of this,
but this explanation helped solidify where they apply and how we reason
about them. Thank you.<br><br>> (We bear most of this cost, but others in the <br>> ecosystem bear some as well.)<br><br>Thank
you for highlighting this. Yes, none of my criticism here is to
belittle the scale of work being done. I want to make sure that we take
the steps that will cause us all the least amount of pain moving
forward.<br><br><br>> Despite these challenges, usability remains paramount.<br>> (Remember too that many proposed hyphenated keywords<br>> are also contextual, unless one or both parts are <br>> existing keywords.). <br><br>Thank
you for highlighting this. Yes, I think my suggestion contributes
nothing unless we use the "Hyphenated classic keywords" strategy.
Otherwise, we end up right back in the same hole with a different
shovel.<br><br>> If there were a better candidate that didn’t have these<br>> challenges, we would have likely preferred that. We did<br>> try &&, which avoided this bullet, but which ultimately<br>> fell afoul of usabilty concerns. <br><br>Good
to know. Could you tell me roughly the time when these discussions
happened on the mailing lists? I try very hard to research these things
before posting, but there's no search bar on the mailing list, and
google is rarely much help. Perhaps I need to get better at googling?<br><br>> No credible alternatives were proposed that avoided the<br>> problem; even most hyphenated options (e.g., `only-when`)<br>> were still contextual, and users would surely have<br>> complained “why do I have to type this long thing.”<br><br>I
can imagine the Amber team's frustration. To be frank, the fact that it
is not 2 characters or less is going to cause some users to complain
about length. I struggle to find the motivation to appease them with my
suggestions.<br><br>> Did you have a better candidate in mind?</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Here
are a few. NONE of these suggestions are context-dependent (at least,
not in the way I have been describing thus far) since they all use a
"classic keyword" as part of the phrase.<br><br>- if ---------- Yes, I
am proposing to repurpose the if statement here. The concept that the
"when clause" represents has strong similarities to an if statement, so
maybe this would allow us to build off of users existing mental models?
And it should appease all of the 2 char, code golf enthusiasts as well.<br>-
case-guard -- Verbose, but clear. No confusion on what this is or
means. If expressiveness/clarity was the only priority, this would
likely be the best choice.<br>- case-if ----- The middle ground between the above 2.<br>- only-if ----- Since "only-when" was suggested before, maybe this one? It's no longer context-dependent now.<br><br>There
are others to be found as well. I believe the below link has all of the
"classic keywords"? We can run through more permutations if none of
mine are good.<br><br><a href="https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html" target="_blank">https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html</a> <------ Someone correct me if this list is not exhaustive or if it is out of date.<br><br>Thank you for your time and insight!<font color="#888888"><br>David Alayachew</font></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 28, 2022 at 9:38 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;">
As you point out, this isn’t really about `when`; if we did as you say for `when`, you’d write exactly the same mail the next time we consider a contextual keyword. What you’re really asking is: “can we please stop using contextual keywords.” (You’ve clearly
read <a href="https://bugs.openjdk.org/browse/JDK-8223002" target="_blank">https://bugs.openjdk.org/browse/JDK-8223002</a> (“Keyword Management for the Java Language”), but others reading this exchange may not have, any may benefit from going back and reading it.).
<div><br>
</div>
<div>Whenever we consider new language syntax, we are called upon to make tradeoffs between many considerations, including: </div>
<div><br>
</div>
<div> - Compatibility with the existing language. (We could declare `when` to be a real keyword, but that would break any code that uses it as an identifier.)</div>
<div> - Naturalness of the improved language. (We could pick a new keyword that is unlikely to conflict with existing code, like `guardedByTheFollowingBooleanCondition`, but writing code in this language would be unpleasant.)</div>
<div> - Complexity for tools and specification. (We bear most of this cost, but others in the ecosystem bear some as well.)</div>
<div> - Progress vs stagnation. (We could choose not to do guards at all.)</div>
<div><br>
</div>
<div>The “keyword management” JEP explicitly acknowledges the challenges with contextual keywords: </div>
<div><br>
</div>
<div>
<blockquote type="cite">
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
<strong>Cautiously consider contextual keywords</strong></p>
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
At first glance, unitary contextual keywords (and their friends, reserved type names) appear to be a magic wand: they let language designers create the illusion of new keywords without breaking existing programs. However, the positive track record of unitary
contextual keywords hides a great deal of complexity and distortion.</p>
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
The process of introducing a unitary contextual keyword is not a simple matter of choosing a word and adding it to the grammar; each one requires an analysis of potential current and future interactions. Each grammar position is its own story: contextual keywords
that might be used as modifiers (e.g., <code style="font-family:SFMono-Medium,"SF Mono","Segoe UI Mono","Roboto Mono","Ubuntu Mono",Menlo,Courier,monospace">readonly</code>) have different ambiguity considerations than those that
might be used in code (e.g., a <code style="font-family:SFMono-Medium,"SF Mono","Segoe UI Mono","Roboto Mono","Ubuntu Mono",Menlo,Courier,monospace">match</code> expression). While a small number of special situations can be managed
in a specification or a compiler, the more heavily that unitary contextual keywords are used, the more likely there would be more significant maintenance costs and longer bug tails.</p>
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
Beyond specifications and compilers, unitary contextual keywords distort the language for IDEs. IDEs often have to guess whether an identifier is meant to be an identifier or a unitary contextual keyword, and it may not have enough information to make a good
guess until it has seen more input. While this is easy to dismiss as “not my problem”, in reality, it results in worse code highlighting, auto-completion, and refactoring abilities for everybody. (IDEs have the same trouble with hyphenated contextual keywords
too.)</p>
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
Finally, each identifier that is a candidate for dual-purposing as a unitary contextual keyword may have its own special considerations. For example, the use of <code style="font-family:SFMono-Medium,"SF Mono","Segoe UI Mono","Roboto Mono","Ubuntu Mono",Menlo,Courier,monospace">var</code> as
a restricted identifier is justified only because the <a href="https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.1" rel="nofollow noopener" style="color:rgb(0,82,204)" target="_blank">naming
conventions for type names</a> are so broadly adhered to. Using a hyphenated contextual keyword rather than a unitary contextual keyword can sidestep these considerations, since the hyphenated phrase has never been used as an identifier, though the ambiguity
issue remains.</p>
<p style="margin:10px 0px 0px;padding:0px;color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(255,255,255)">
In summary, unitary contextual keywords are a tool in the language design toolbox, but they should be used with care.</p>
</blockquote>
</div>
<div><br>
</div>
<div>Despite these challenges, usability remains paramount. (Remember too that many proposed hyphenated keywords are also contextual, unless one or both parts are existing keywords.). </div>
<div><br>
</div>
<div>If there were a better candidate that didn’t have these challenges, we would have likely preferred that. We did try &&, which avoided this bullet, but which ultimately fell afoul of usabilty concerns. No credible alternatives were proposed that
avoided the problem; even most hyphenated options (e.g., `only-when`) were still contextual, and users would surely have complained “why do I have to type this long thing.” </div>
<div><br>
</div>
<div>Did you have a better candidate in mind? </div>
<div><br>
</div>
<div>
<div>
<div>
<div><br>
<blockquote type="cite">
<div>On Nov 27, 2022, at 7:07 PM, David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div style="font-family:monospace" class="gmail_default">Hello Amber Dev Team,<br>
<br>
In regards to when clauses, is it possible that we could use a keyword for when clauses that is not the "context-dependent" style keyword? And when I say "context-dependent", I mean that the word "when" is a valid identifier, but we are using context to be
able to figure out where it should be treated as a keyword vs. an identifier. <br>
<br>
The reason I am requesting this is because everytime a context-dependent keyword is added to Java, all the developers who make language/grammar parsing tools for the Java language have to rewrite/uproot nontrivial parts of their code to deal with several finnicky
edge cases. It bogs down so much of the parsing logic that a lot of potential optimizations or cleaner solutions go out of the window. This leads to buggy code and/or features not being supported. Much of that could be avoided by choosing a keyword that is
not context-dependent. I understand that there does exist a grammar for the language, but because<br>
<br>
Personally, I'd like it if as a language, Java never used this tactic for any new language feature. But for now, I am only requesting that we use a non-context-dependent phrase to signify when clauses. One suggestion would be to use the "Hyphenated classic
keyword" strategy discussed in this JEP Draft (<a href="https://openjdk.org/jeps/8223002" target="_blank">https://openjdk.org/jeps/8223002</a>).<br>
<br>
Thank you for your time and patience!<br>
David Alayachew</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote></div>