Could we change the syntax for when clauses?

[Brian Goetz]

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  https://bugs.openjdk.org/browse/JDK-8223002 (“Keyword Management for the Java Language”), but others reading this exchange may not have, any may benefit from going back and reading it.).

Whenever we consider new language syntax, we are called upon to make tradeoffs between many considerations, including:

 - 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.)
 - 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.)
 - Complexity for tools and specification.  (We bear most of this cost, but others in the ecosystem bear some as well.)
 - Progress vs stagnation.  (We could choose not to do guards at all.)

The “keyword management” JEP explicitly acknowledges the challenges with contextual keywords:


Cautiously consider contextual keywords

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.

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., readonly) have different ambiguity considerations than those that might be used in code (e.g., a match 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.

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.)

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 var as a restricted identifier is justified only because the naming conventions for type names<https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.1> 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.

In summary, unitary contextual keywords are a tool in the language design toolbox, but they should be used with care.

Despite these challenges, usability remains paramount.  (Remember too that many proposed hyphenated keywords are also contextual, unless one or both parts are existing keywords.).

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.”

Did you have a better candidate in mind?


On Nov 27, 2022, at 7:07 PM, David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

Hello Amber Dev Team,

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.

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

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 (https://openjdk.org/jeps/8223002).

Thank you for your time and patience!
David Alayachew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221128/63386313/attachment-0001.htm>